Problems verifying integers

I'm curious if anyone has run into this and has a better solution. I have a site with a variety of search fields. One of these fields allows for a search string...if string value, it searches matching description/text fields. If an integer, it matches the primary key value. Pretty straightforward. The problem is that I haven't found a really reliable way in CF to make sure that the integer is indeed a DB-safe integer, so hack attempts constantly cause errors to get thrown. isNumeric() lets way too much stuff through. So I switched to isValid("integer") which did a little better. But it seems to still allow stuff like commas and even currency symbols, passing them through as a valid integer. LSParseNumber will fix the commas, but it throws errors for the currency symbol. So I've had to resort to using a RegEx to strip out any non-numeric stuff. Does this seem odd to anyone else? I would think there would be some way these functions would work to prevent passing invalid data to a cfsqlparam with type cf_sql_integer but I couldn't find a way that didn't allow something illegal through. FYI, I believe this is a CF8 server, so maybe this kind of issue has been corrected? Mary Jo

Mary, I think val() is what you are looking for. If it is a not a number it just returns 0. -J.J. ----- Excess quoted text cut - see Original Post for more -----

> I would think there would be some way these functions would > work to prevent passing invalid data to a cfsqlparam with type > cf_sql_integer but I couldn't find a way that didn't allow something > illegal through. If I know a variable is supposed to be an integer (usually a primary key), I will do: <cfparam name="url.id" default="0"> <cfset url.id = abs(val(trim(url.id)))> This will force the value to a positive integer or zero.  If you just want to test the variable to see which search type should be triggered: <cfif abs(val(trim(url.id))) eq url.id)>    <!--- Is positive integer ---> <cfelse>    <!--- Not so much ---> </cfif> If people are entering values that could include dollar signs and commas that need to be considered, a regex to remove non-numeric characters (expect perhaps a period) would probably be the better choice, or at least a replaceList() to remove the commonly used but undesired characters before passing it through a sanitizer. At one point (years ago) Google was hitting pages and throwing very large numbers into some integer URL variables which caused an out-of-range error and I even added a min() function with the resulting "sanitized" value and 2000000000 as the parameters to keep the value in range, though I haven't seen that for a while, but something to keep in mind if you see an error like that come up. -Justin

Thanks guys, sure there's other ways to FIX the number, but that wasn't exactly my question. I just find it weird that isValid("integer") would consider $123,123 as a valid integer value....such that I have to fix it in the first place! That sure wouldn't pass in another language, and yes, I know this is not a strongly typed language. I just find it frustrating, that this function doesn't seem to perform what it's intended to so I have to add additional logic to see if what was entered really was an integer or not. Justin...you're right about huge numbers passing too...I think that was actually why I switched from isNumeric() which allowed those through to the isValid() function which doesn't. Mary Jo ----- Excess quoted text cut - see Original Post for more -----

Yeah unfortunately IsValid("integer") ignores non-numeric characters. (I wish they offered a setting for that behavior) Anyway, you might try a "range" or "regex" match instead. I believe those comparisons are more strict.   -Lei

> Yeah unfortunately IsValid("integer") ignores non-numeric > characters. It seems more complex than that, as some it will ignore and others it won't.  Dollar signs and commas appear to be ignored but others are not (results as run on ColdFusion 9). <cfoutput> 123,,123 = #isvalid("integer", "123,,123")# <!--- YES ---> <br> x123,,123 = #isvalid("integer", "x123,,123")# <!--- NO ---> <br> 123,x,123 = #isvalid("integer", "123,x,123")# <!--- NO ---> <br> 123,&,123 = #isvalid("integer", "123,&,123")# <!--- NO ---> <br> *123,123 = #isvalid("integer", "*123,123")# <!--- NO ---> <br> $123,123 = #isvalid("integer", "$123,123")# <!--- YES ---> <br> </cfoutput> Personally, I don't consider either to be part of an integer value and I don't think it should ignore any non-numeric characters, but I suppose they have their reasons for implementing it this way (unless it's a long-standing bug that too much code is dependent upon to fix). -Justin

> It seems more complex than that, as some it will ignore and others it > won't.  Dollar signs and commas appear to be ignored but others are > not (results as run on ColdFusion 9). Yeah, I do not know all of the rules. But the internal class for "integer" validation has a boolean setting that determines whether it ignores non-numeric noise. It is enabled by default, which would explain why it accepts some wacky characters.  I have not tested it in detail, but  a "range" validator (ie using -2147483648 / 2147483647) seems to produce results more in line with that I would expec

> but  a "range" validator (ie using -2147483648 / 2147483647) seems to produce results more in > line with that I would expect I spoke to soon. "range" has better handling for non-numeric characters and the overall range. But does not validate they are whole numbers .. (doh). -Leigh

> I just find it weird that isValid("integer") would consider $123,123 > as a valid integer value....such that I have to fix it in the first place! I agree that seems a little wonky.  I ran the code below to test some values with ColdFusion 9 and the results are included in the inline comments: <cfoutput>   $123,123.00 = #isvalid("integer", "$123,123.00")# <!--- NO ---> <br>   123,123.00 = #isvalid("integer", "123,123.00")# <!--- NO ---> <br>   123,123 = #isvalid("integer", "123,123")# <!--- YES ---> <br>   $123,123 = #isvalid("integer", "$123,123")# <!--- YES ---> <br>   4,123,123 = #isvalid("integer", "4,123,123")# <!--- YES ---> <br>   4,123,123,123 = #isvalid("integer", "4,123,123,123")# <!--- NO ---> <br>   123,,123 = #isvalid("integer", "123,,123")# <!--- YES ---> <br> </cfoutput> It will accept the dollar sign ("$") and even a double comma (",,") as part of an integer value, but not a decimal point (".00").  I can see how that would be frustrating as I would expect it to handle some of those differently.  I've been sanitizing integers on my own since ColdFusion 4, so this isn't something I've really bumped into.  I do use isValid() for verifying e-mail address formats in some places, so I'm beginning to wonder what problems exist in that algorithm, if any. Hmm... -Justin

>I agree that seems a little wonky.  I ran the code below to test some >values with ColdFusion 9 and the results are included in the inline >comments: > Cool, thanks for verifying that it's equally as wonky on later versions. In my case, it's not a huge deal to sanitize what passes, I mostly was annoyed that I had to add additional code just to get it to work the way it seems to be intended. Maybe I'll put in a bug report on it.... Mary Jo

> Cool, thanks for verifying that it's equally as wonky on later > versions. In my case, it's not a huge deal to sanitize what passes, I > mostly was annoyed that I had to add additional code just to get it to > work the way it seems to be intended. Maybe I'll put in a bug report > on it.... Here you go if you want to vote on it: https://bugbase.adobe.com/index.cfm?event=bug&id=3169196 Mary Jo

>Here you go if you want to vote on it: > >https://bugbase.adobe.com/index.cfm?event=bug&id=3169196 Thought I'd post a followup on this, Adobe closed it saying they wouldn't fix this because it would cause backward compatibility issues. Personally I can't imagine using isValid("integer") and WANTING currency symbols and commas to go through, so guess I'll just have to keep writing my own functions for doing this. It's annoying sometimes the illogic that is often left in a language in the interest of backwards compatibility. You end up with stuff like this that just can't even be used for its intended purpose. Mary Jo

Depending on the version of ColdFusion the OWASP ESAPI is included. You could use the isValidInteger function of that. It even lets you specify a minValue and maxValue. If you have CF8.01 or higher you have ESAPI.  It may be an older version, but you can always upgrade the esapi as well by putting in the latest jar file. Steve > Cool, thanks for verifying that it's equally as wonky on later > versions. In my case, it's not a huge deal to sanitize what passes, I > mostly was annoyed that I had to add additional code just to get it to > work the way it seems to be intended. Maybe I'll put in a bug report > on it.... Here you go if you want to vote on it: https://bugbase.adobe.com/index.cfm?event=bug&id=3169196