ColdFusion 9：int和type =“numeric”讨厌的bug？ [英] ColdFusion 9: int and type="numeric" nasty bug?

问题描述

我刚刚遇到一个违反任何逻辑的行为，可能会导致严重的问题，并想知道这是一个错误，或者行为是否被推翻，什么是最佳实践来规避问题？

以下是两种行为，当它们组合在一起时，会对任何系统的数据完整性构成威胁。

1. int（'1 2'） - > 41276


2. isValid（'numeric'，'1 2'） - > true

为什么？好，让我们看看...

 < cffunction name =deleteSomethingaccess =publicreturntype =void> 
< cfargument name =somethingIdtype =numericrequired =yes> 
 
< cfquery datasource =＃dsn（）＃> 
 DELETE 
 FROM Something 
 WHERE id =< cfqueryparam cfsqltype =cf_sql_integervalue =＃arguments.somethingId＃> ;; 
< / cfquery> 
 
< / cffunction> 
 
 
< cfset deleteSomething（'1 2'）> 
  

这里， type =numeric参数验证（可能基于与 isValid ？相同的算法）不会使用'1 2' 。更糟糕的是， cfqueryparam cfsqltype =cf_sql_integer似乎使用 int 来转换值， code> 41276 。

换句话说， deleteSomething（'1 2'）将删除id 41276 的实体，而不是抛出异常，因为值 1 2 显然不是数字。

现在，我想到的唯一的修复是使用 isValid（'integer'，... 或正则表达式，但这是一个真正的痛苦，除此之外，我从来没有理解为什么他们没有实现 type =integer？

$ b显然，我也总是假设 cfqueryparam type =cf_sql_integer将验证传递的值是一个有效的整数。 / p>

编辑：

似乎即使无效（'integer'，... 也不可靠，我们可以在
中看到
Why isvalid（" integer"，" 1,5" = YES？

EDIT2：

我知道我可以为每个函数中的每个预期的整数参数添加additionalnal参数验证，但是这将需要修复一个巨大的代码库在我的情况，它也很容易出错。这也使得内建的参数验证在这种情况下完全无用。

我宁愿选择一个解决方案，我可以创建和应用非官方补丁<强>。这是一个现实的选择吗？

解决方案

这是另一个问题的主题变体。查看此代码（或在 cflive.net 上运行此代码）：

 < cfscript> 
 s =1 2; 
 i = int（s）; 
 v = isValid（numeric，s）; 
 d = createOdbcDate（s）; 
 writeDump（[s，i，v，d]）; 
< / cfscript> 
  

s 转换为 createOdbcDate（）时，调用 int（） c>，我们得到：

  2013年1月，02 00 00:00:00 +0000 
  

因此1 2被解释为md ，包含当年的隐含年份。

这是完全愚蠢的。但你去。

I've just experienced a behaviour that defies any logic and could potentially lead to serious issues and was wondering if it was a bug or if the behaviour was itended and what are the best practices to circumvent the issue? If it's a bug, is there a patch?

Here's the two wierd behaviours that when put together are a threat to any system's data integrity.

1. int('1 2') -> 41276
2. isValid('numeric', '1 2') -> true

Why? Well let's see...

<cffunction name="deleteSomething" access="public" returntype="void">
    <cfargument name="somethingId" type="numeric" required="yes">

    <cfquery datasource="#dsn()#">
        DELETE
        FROM Something
        WHERE id = <cfqueryparam cfsqltype="cf_sql_integer" value="#arguments.somethingId#">;   
    </cfquery>

</cffunction>


<cfset deleteSomething('1 2')>

Here, the type="numeric" arguments validation (which perhaps is based on the same algorithm as isValid?) doesn't throw with '1 2'. Even worse, cfqueryparam cfsqltype="cf_sql_integer" seems to be using int to convert the value which will end up being 41276.

In other words, deleteSomething('1 2') will delete the entity with id 41276 instead of throwing an exception since the value 1 2 is obviously not numeric.

Now, the only fix I thought of is to perform additionnal argument validation using isValid('integer', ... or a regular expression, but that's a real pain and besides, I never understood why they haven't implemented type="integer"?

Obviously, I also always made the false assumption that cfqueryparam type="cf_sql_integer" would validate that the value passed is a valid integer.

EDIT:

It seems that even isvalid('integer', ... is also not reliable as we can see in
Why isvalid("integer","1,5") = YES?

EDIT2:

I know that I could add additionnal arguments validation for every expected integer argument in every function, however that would require to fix a huge code base in my case and it's also very error-prone. It also makes the built-in argument validation completely useless in this case.

I would rather prefer a solution where I could create and apply an unofficial patch. Is that a realistic option? If so I would like to be pointed out in the right direction.

解决方案

This is a variation on that theme from the other question. See this code (or run it on cflive.net):

<cfscript>
s = "1 2";
i = int(s);
v = isValid("numeric", s);
d = createOdbcDate(s);
writeDump([s,i,v,d]);
</cfscript>

s converts to 41276 when calling int(), and when using it as an input for createOdbcDate(), we get:

January, 02 2013 00:00:00 +0000

So "1 2" is being interpreted as "m d", with an implied year of the current year.

Which is utterly stupid. But there you go.

这篇关于ColdFusion 9：int和type =“numeric”讨厌的bug？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！