CFINPUT VALIDATE INTEGER NOT WORKING PROPERLY

[jackhuang]

The CFINPUT with the VALIDATE="integer" is not working properly at all.  The user can enter 23,950 as the number.  We would think this is OK but it won't work properly without stripping the ","

The field:

<CFINPUT TYPE="text" NAME="mynumber" VALIDATE="integer" MESSAGE="mynumber must be an integer">

Then, when the value is passed to the SQL INSERT

<CFQUERY....>

INSERT INTO mytable

(name, mynumber)

VALUES

(#'form.name#',#form.mynumber#)

</CFQUERY>

Coldfusion will take the value 23,950 and think that 23 is one field and 950 is another because of the ","   Therefore it is trying to put 3 values into 2 fields and throw an error.  Am I doing something wrong here or is this Coldfusion bug?

p.s. in the MySql database, the "mynumber" field is defined as integer.

[duncancumming]

This is a stupid bug where CF allows for commas in integers, see

Adam Cameron's CFML Blog: According to ColdFusion "0,6" == "6,0". And both are integers to boot

Adam Cameron's CFML Blog: ColdFusion 11: Adobe goes some way to correctly identifying what constitut...

Adam Cameron's CFML Blog: Can we please agree that Adobe is not the arbitor of what constitutes an i...

Strongly suggest you ditch <cfinput>, use normal <input> tags and write your own JS (or use a framework) to do the validation.

[SRolly]

In earlier versions of CF a comma in a numeric field was rejected by the javascript code in cfform.js.  In CF11 it's passed on to create errors in MSSQL update statements.  I extracted the relevant code from cfform.js and ran it against a <form..>..</form> rather than <cfform..>..</cfform> and it correctly trapped commas.  The error appears to have something to do with how Adobe packages the code appearing in cfform-src.js into cfform.js.  This error should have been handled long ago.  I've submitted a bug report a week ago (9/14/15) with no repsonse.  If Adobe is serious about Cold Fusion they need to fix this.

[WolfShade]

This exact discussion is happening in another CF thread. 

HTH,

^_^

[mkane1]

Totally agree that the cfinput bug should have been fixed long ago. But it should not be that big a deal. Javascript validations, whether generated from cfinput or by custom script, are great but should never be solely relied upon, especially for inputs that will be used for database actions. All such inputs should be validated with server side code.

I've had lots of apps where the clients require being able to enter large integer numbers (millions of units) with commas to visually help them ensure the numbers are correct. Sometimes we use Javascript to validate/convert the values, but we *always* use server side code to fully validate input.

Also, a couple of things about the code above. The second apostrophe in #'form.name#' is misplaced, it should be before the pound sign. More importantly, directly using form inputs is not at all good. At the least, be sure to use cfqueryparam for all user inputs. Better still, initialize, sanitize, and validate all user input first. Usually, it is best to initialize local variables and then use the values of FORM inputs etc. after validation.

[Steve Sommers]

The last part of mkane1's statement cannot be emphasized enough: use cfqueryparam, initialize, sanitize, validate...

To prove the point, disable scripting in your browser and enter the following in the mynumber field (without the quotes): "0 );delete from mytable where (1=1"

You'll be amused by the results -- but I suggest you make a backup copy of your database first!