regexcoldfusioncfmlcfformbluedragon

Regular Expression in BlueDragon 7.1 is allowing $ sign


I'm using the BlueDragon's cfform validation:

<cfinput validateat="onServer" validate="regex" pattern="^[a-zA-Z0-9 ]+$"  name="COMPANYDBA" />

But this pattern isn't producing the right result. Something is up with the dollar sign: ^[a-zA-Z0-9 ]+$

Expected result: no special characters

Actual result: no special characters except it's allowing the $ sign

Why in the world would this allow a dollar sign in the string?


Solution

  • An old question, but it's listed as unanswered, so here's an (overly-long) answer to stop that being the case (as soon as someone upvotes it, anyhow).

    It's unlikely the source for cfform has changed significantly between BD7 and OpenBD -- because pretty much nobody recommends using cfform these days -- so here's the OBD code which generates the HTML:

    http://websvn.openbd.org/websvn/filedetails.php?repname=OpenBD&path=%2Ftrunk%2Fsrc%2Fcom%2Fnaryx%2Ftagfusion%2Fcfm%2Fcfform%2FcfAbstractFormTag.java

    What this code tells us is that, with the attributes provided, a hidden form field named with the suffix _CFFORMREGEX is output with the pattern to test.
    (Which of course is not real server-side validation, despite whatvalidateat="onserver" suggests, and thus is yet another reason not to use cfform).

    After submission, that form field is picked up and used via the cfFormData.java file:

    http://websvn.openbd.org/websvn/filedetails.php?repname=OpenBD&path=%2Ftrunk%2Fsrc%2Fcom%2Fnaryx%2Ftagfusion%2Fcfm%2Fengine%2FcfFormData.java

    Which if you follow it through eventually runs the pattern through com.nary.util.string.regexMatches which uses Apache ORO to check it matches:

    http://websvn.openbd.org/websvn/filedetails.php?repname=OpenBD&path=%2Ftrunk%2Fsrc%2Fcom%2Fnary%2Futil%2Fstring.java

    The use of SINGLELINE_MASK means the ^ and $ will perform their usual start/end of content match (not start/end of lines) and that . includes newlines.

    With all that, we can categorically state that, if the pattern provided is ^[a-zA-Z0-9 ]+$ then $ will not be accepted, so there must be more to the original issue than has been revealed.

    Of course, rather than worrying about all that, the most appropriate solution is: stop using cfform.

    There are plenty of superior options for doing proper form validation, see Charlie Arehart's list: cf411.com/form