Twitter: raymondcamden


Address: Lafayette, LA, USA

Forms not working on your ColdFusion server? Size matters.

05-14-2013 4,736 views ColdFusion 17 Comments

I've come across multiple people lately who have been bitten by this so I thought a quick blog post would be useful for my readers. If you've recently upgraded your ColdFusion server or patched it, you may find some forms return an error when submitted. Here is an example:

To cause this error, I simply created a form with 101 fields like so:

If you modify the loop to go to 100 instead of 101, it works fine. People using ColdFusion 10 or a recently patched ColdFusion 9 will encounter this.

The cause is a recent security fix. You can read the details here (Adobe ships patch for ColdFusion flaw that could lead to DoS attacks), but most likely you are only concerned about how to get around this.

In the ColdFusion 10 Administrator, under Settings, way at the bottom, you will find this new setting:

You can tweak this to a value that makes sense for your form. For folks using ColdFusion 8 and 9, you have to edit a bit of XML to handle this. Details may be found here: ColdFusion Security Hotfix APSB12-06.

Edit:
A few minutes after I posted this blog post I tried a quick experiment. In ColdFusion 10, you can finally now take form fields of the same name and use this as an array. If you add this.sameformfieldsasarray = "true"; to your Application.cfc and post 2 form fields with the same name, their value in the form scope will be an array. I recommend this setting in general as a list (the normal behavior) cannot be reliably decoded. Turns out, if you use the same field name, you can post any number of form fields you want. I tried with 200, no problem. If you also do the sameformfield thingy, the values work just fine.

17 Comments

These comments will soon be imported into Disqus. To add a comment, use Disqus above.
  • Brian Thornton #
    Commented on 05-14-2013 at 9:09 AM
    Great post
  • Dinesh Kanwar #
    Commented on 05-14-2013 at 9:10 AM
    And what about xml http requests? Are they effected by this too or not?
  • Commented on 05-14-2013 at 9:11 AM
    Dinesh, do you mean via AJAX? It is still a POST request, so yes. Btw, you guys posted quick. Be sure to read my Edit at the end.
  • Will Swain #
    Commented on 05-14-2013 at 9:15 AM
    I just figured this issue out yesterday. Was seeing it on a fresh 9.0.2 install. Particularly annoying since it just gives a 500 error and no further details.
  • Dinesh Kanwar #
    Commented on 05-14-2013 at 9:19 AM
    Regarding your edited post, I do not think having form fields with same name is practically viable. Is it? And I do not think I need any setting in app.cfc for that. Its forms default behavior to have values in list when you have same name form field. Just like a checkbox or radio. Well, you are probably the first person to know what has changed in adobe and if anything would have gone wrong related to this on my app, I always find only one place to go : Jedimaster's blog. Lucky this time I know in advance. :)
  • Commented on 05-14-2013 at 9:23 AM
    Dinesh: "I do not think having form fields with same name is practically viable. Is it?" Actually, they could have some value. Any time you need a set of related fields, for example, maybe kids names. Normally we do something like

    kid1
    kid2
    kid3

    etc. But having one field called kid is more convenient,simple.

    "Its forms default behavior to have values in list when you have same name form field."

    No, that's just how CF did it. PHP, for example, gave you an array. I'd rather use an array.
  • Commented on 05-14-2013 at 9:45 AM
    I saw sameformfieldsasarray mentioned in your latest CFWACK book and thought that I would use it, but on an existing application, you'd have to go through all the source code to see if it affects any pages with type="checkbox".

    Q: Can you use sameformfieldsasarray for a single form?
  • Commented on 05-14-2013 at 10:03 AM
    As far as I know, no. But - you can get access to the PageServlet and the Form data and do something similar. I know I blogged about it a long time ago.
  • Michael Schmidt #
    Commented on 05-14-2013 at 11:12 AM
    If my memory serves me correctly, the methods of getting multiple form fields as arrays has actually been "broken" by ColdFusion 10.

    By broken the Automatic new method for converting form fields to array collapses empty elements so if you have a repeated row type that has a consistent form fields for that row if an text input or something is empty it will collapse and ignore it. The old method of getPageContext().getRequest().getParameterMap() doesn't work any more, and the only way i have been successfully able to get something to work is if i change the enctype on the form to multipart/form-data and use FORM.getPartsArray()
  • Commented on 05-14-2013 at 11:17 AM
    Wow, confirmed. It does collapse it. Of course, it does so for lists as well.

    I'm curious what PHP does.

    Michael, thanks for sharing this.

    So my take away is this. If you have N fields and the lack of a field is important (it may not always be!), then you cannot use N fields with the same name. Period.
  • Commented on 05-14-2013 at 11:32 AM
    I had someone on Twitter test PHP. PHP does it right. Given 3 fields with the same name, and you leave field 2 blank, you will get an array with the second element empty, which is what it was obviously.

    So - someone should file a bug report for this I think.
  • MikeZ #
    Commented on 05-14-2013 at 9:44 PM
    Nice to see that the resulting error is almost as useless as its counterpart in CF9 (where there seems to be no trace in the logs whatsoever).
    The lack of a useful log entry made it harder than necessary to track down that parameter in the neo-runtime.xml
  • Commented on 05-15-2013 at 5:27 AM
    I believe (stress, believe) the useless error is to help hide the fact that this is trying to prevent a DDOS type attack.
  • Will Swain #
    Commented on 05-15-2013 at 5:38 AM
    Something more verbose, or just anything, in the cf logs files would be nice though. Almost impossible to debug.
  • Commented on 05-15-2013 at 5:42 AM
    Good point about the logs - that could certainly be more verbose. I'd encourage you to file a bug report on that.
  • Commented on 05-15-2013 at 6:50 AM
    This one crops up now and again. Recently (and no code changes) after a recent patch. Like Will says the error gives nothing at all away. Then I remembered the POST LIMIT and had to explain to SysAdmin how to fix it. Ditto on Will's suggestion for debugging. From memory nothing from the logs gave any indication. Sigh!
  • Commented on 05-18-2013 at 1:08 AM
    Hi Ray,

    CF used to ignore this.sameformfieldsasarray="true", if setEncoding("form", ..) used certain encodings. I believe they fixed the issue for all setEncoding()'s encoding options, except for one of them. I mentioned the non-existent logging to them (forget if a bug was filed), but apparently the logging issue has not been fixed.

    Thanks,
    -Aaron