I got it working, it was totally my fault. I searched my neo-runtime.xml file for postParametersLimit and found nothing so I added it after postSizeLimit per the instructions. Turns out my file did have a postParametersLimit in it, but it didn't come right after postSizeLimit so I didn't notice it and I must have searched for the wrong thing (probably forgot the "s" in "Parameters"). So after removing the duplicate entry, everything worked fine. Felt stupid wasting an hour on this, but it could have been worse if I hadn't spotted the duplicate!
Good to hear you resolved it. But you should now remove those CHF1 and 2 jar files you added (per your note in this thread at http://forums.adobe.com/message/4297879#4297879), when you had CHF 3 already. They are cumulative. You do not need the earlier ones if you install the later ones. And in that you also said in another message that you added CHF 4, you should remove the CHF 3 jar. But be careful to ONLY remove those that start with chf (for 1, 2, and 3), not any for HF (individual hotfixes) unless a technote tells you to remove them.
One other thought on this: one other conclusion from this is that people should not “just add” the line about postParametersLimit if they are finding this thread to solve the problem.
They should first check if the string is already in the neo-runtime.xml file. To be clear, it’s not there unless and until someone reads the technote (for the hotfix) and adds it. (the postsizelimit has been there at least since CF7, and is controlled via a setting on the CF Admin Settings page).
But it could be that you (dear reader of this thread) may be finding this thread in order to “solve” the problem of your now getting an error when trying to post a form submission. And someone else on your server may have applied the HF which imposed the new limitation (of number of form fields that can be posted, as a security fix). That person applying the fix may not have raised the postParametersLimit value high enough for your specific application’s needs.
So again, don’t “just add the lines” for postParametersLimit. That’s what the technote says to do when you are applying the hotfix. The lesson to be learned from the experience of some others in this thread is that if you are NOT the one applying the hotfix, don’t mistakenly “add the lines” for postParametersLimit. Check first if it’s there (from someone having applied the hotfix), and if so, update the value instead.
Finally, I’m pretty sure changing that value in that file will require a restart of CF for it to take effect, at least until Adobe updates the Admin so that you change it instead in the interface, where they could cause the xml file to be reloaded.
I have a form designed by one of our partners that has exactly 101 form elements.
Something I am running into is that after editing neo-runtime.xml & performing a restart, all seems ok, until... Until I make a change via the CF Admin. After that, the
<var name='postParametersLimit'><number>xxx.0</number></var> line is removed.
According to http://helpx.adobe.com/coldfusion/kb/coldfusion-security-hotfix.html, "We are not exposing this setting in ColdFusion Administrator console, but this limit can be easily changed in neo-runtime.xml file." Thus, I believ by not exposing it via the CF admin console, that setting is ignored upon any console cahnges/updates. Not very helpful at all. Tie another string around my finger for things to remember to do when I perform task xyz.
It may be possible that the reason it’s not written when you edit is that it’s possible that they changed the Admin code to write it (even without exposing it in the interface), but perhaps while applying this or another update you did not properly update the CFIDE directory that underlies your CF Admin. I see this happen often, as people sometimes have more than one CFIDE, and might pick the “wrong” one. Start by checking what’s defined in the CF Admin Mappings page.
But that’s not enough, sadly. What matters more is where the docroot is for the website in the web server you use to run the CF Admin. If using a port (like 8300, 8500, etc) then you’re likely using CF’s built-in web server, and its docroot (and place to find and update the CFIDE) is generally Re: APSB12-06 and errors\wwwroot. If using IIS or Apache, then it’s wherever the docroot is for the website you’re using there.
Some people have duplicated their CFIDE and placed copies in different docroots, whether for use by the code that their CFML creates (some of which calls back to the server for some subdirs of CFIDE) or simply because they wanted be able to access the CFAdmin in different web sites. Sure, they could have created virtual directories instead, but many go the simple route. And so when hotfixes are applied that require updating the CFIDE, the person doing that may do only the “one” they think is in use by CF, when in fact it could be many.
And that then could leave you in the state you’re in. Just a guess. Could be wrong. Just an idea, if it may help.
PS If anyone would wonder, “well if they CF Admin is accessed by way of different CFIDE dirs in different web sites, then wouldn’t that mean I’d see different results saved in the CF Admin if accessed these different ways”, the answer is “no”. The CF Admin writes its results back to the server, typically in Re: APSB12-06 and errors\lib\neo-*.xml files. It does not write back to the CFIDE dir itself. So, again, some people can be suffering from this problem of different sites using subtly different CFIDE codebases, and they may not readily notice it at all, until quirky things like the below might happen.
Thnx for the reply, and I think you nailed it on your opening statement. "It may be possible that the reason it’s not written when you edit is that it’s possible that they changed the Admin code to write it (even without exposing it in the interface)". I failed to heed the warning of an earlier post and there may have already been an entry with a value of 100. I placed mine directly after the postSizeLimit and later found it missing. Knowing that the file is written in whatever order the server wants to place the elements, I went searching for '
postParametersLimit' and discovered '
This sort of demosntrates that the Admin code does placed it with a default value of 100, but not neccessarily where I expected to find it. I reset the value to what I wanted, restarted the server, and then made several edits via the CF Admin, thus proving I was expeiencing an ID 10 T error.
Without derailing the topic: With regards to the whole /CFIDE/ topic, my practice has been to create two folders for each server instance. One that is a target for the sites served by said instance that does not contain the adminapi and similar folders, thus not exposing the admin api, that is a virtual fodler target for said sites. The other folder is targeted by an internal only web site for administering each server instance, thus only exposing the CF Admin thru a site that can only be reach by LAN clients. This makes managing updaets a bit easier. Curious what others do.
Glad to hear that you solved it.
As for your approach to managing the CFIDE directory for various uses, there are lots of ways to solve things, each with their pros and cons in terms of maintainability, security, etc. Not really any one right way. It would be a useful blog entry for someone to outline the many approaches and their implications, in both the near and long term (meaning with respect to applying updates, etc.)
This hotfix is causing crazy problems and I think part of the issue is the description of the fix for the forms. It tends to imply that the default value is 100 and if you need more, feel free to change it. The default value is in fact 15, so I think everybody will need to change this.
I just went and looked at a fresh isntall withonly the update applied and no changes to neo-runtime.xml
I'm lost as to where you came up with 15, but curious. My biggest problem was haste, oversight, not paying attention to the previous warnings in this thread. The docs mention to jump to Section 2 if certain conditions apply. This caused me to not pay attention to the Notes section. The notes also mention that you want to place the 'postParametersLimit' right below 'postSizeLimit'. Thus, not finding it there, I believed it wasn't yet in the file.
This needs to be a per application setting and not just a global setting. We have forms with 300 form fields and from a security perspective, that shouldn't be the server baseline. Hopefully, CF10 will address this. Since this is called postParameterLimit, does anybody know if processing cfparam or cfqueryparam gets included in the count? If not, why not change the name to formFieldLimit?
Stephen, you won’t find this setting there, until you apply this fix.
Like Dan, I’m curious where you’re getting your 15 from. You seem quite confident. When you say “if the setting has been there, it was set at 15”. So do you mean, in some of your servers, in that xml file, you find that setting, and it’s set at 15? You or someone there had to have put it there, from everything I know about this issue.
Stephen, no, it has nothing to do with those other “parameters”. That word is used generically throughout CFML and indeed IT in various ways (good ol’ parameterexists was the way to test for variable existence before isdefined). I suspect in this case the engineer picking it did so without any consideration of the use of the word elsewhere in CFML.
As for the name of the xml element, well, the hotfix is about form submissions, via an http post method, so the “formpost” part is at least technically correct, if perhaps not as user friendly as it could be. And then they needed a metric to count how many of those per request would be permitted, and they chose “parameter”. They could have chosen “count”, or perhaps others. So yes they could have picked “formfieldlimit”, or one might argue that even “formfieldcountlimit” would be more accurate. Or “formfieldmaxcount”, and so on.
But the name is a pretty low-priority issue, I think, and I doubt they’d revisit it. Just one person’s opinion. We’ve just not seen much from Adobe on this issue here, so I’m just offering at least one reply for you sine you feel the matter deserves consideration. Hope that’s helpful.
We applied the hotfix to all of our servers (10) and 2 had a value of 15 and the rest didn't even have the setting. I am the only one who has attempted to modify the neo file, so I am fairly confident in my findings. We ended up rolling back to hotfix 3 on most of the servers because of the high form field count. As far as the naming, it is a very low priority issue. I still think it should be an application level setting (this.postParametersLimit) to allow admins to set a low default value and overide on a per application basis.
As always, thanks for taking the time to respond.
Fair enough, Stephen, and thanks for the kind regards. But do you understand that the setting can only get there if you put it there (whether it’s there at all, or there with a value of 15)?
This is discussed in note 5 in the technote, http://helpx.adobe.com/coldfusion/kb/coldfusion-security-hotfix.html. You just seem to be asserting that it got there somehow another way. It cannot. And if it’s not there, than as the note indicates, the default is 100. You only need add the xml element if you want to change that.
As for hoping it might be made more app-level instead, I can appreciate the value in that. We can hope that the Adobe engineers will see this and consider it. But you may be better off filing that as an enhancement request, at https://bugbase.adobe.com/.
Hope that’s helpful.
We encountered the "coldfusion.filter.FormScope$PostParametersLimitExceededException: POST parameters exceeds the maximum limit specified in the server." error after a fresh installation of ColdFusion 9.0.2 (the edition without Verity).
The CF9 Administrator does not have a setting for this option (whereas the CF10 Administrator does), so we edited the neo-runtime.xml file to increase the parameter to 5000.0 as suggested above and that solved the issue for us.
We can all wish it was so, Pete, but sadly, no.
“The setting is not exposed in the ColdFusion Administrator console, but it can be modified in the neo-runtime.xml file.”
Perhaps it may be offered in another updater some day.
Does anyone know if it's possible to read this setting procedurally, even with undocumented APIs? Our support staff has access to a code execution environment on some remote servers, and wants to be able to check it.
Yes, Dave, by way of the AdminAPI, which is available in both Standard and Enterprise editions of CF. See the runtime.cfc’s getRuntimeProperty method. Here’s one very simplistic example of code to get it: just change it to your user CF Admin password.
Thanks for getting back, and for the general steer, but the code in your post got eaten. I tried the code below (which probably also won't come through), but the result is undefined. My guess is that all I need is the right name for that parameter, assuming it's readable via the API. If you or anyone else knows where I could find docs or other info on this, it'd be great.
runtime = createObject("component","CFIDE.adminapi.runtime");
prop = runtime.GetRuntimeProperty("postParametersLimit");
Bummer. I hate when that happens (that forums or mailing lists hide or munge code when we offer it.) Here it is again, without the opening and closing brackets (and sure, it could be done as pure CFSCRIPT as well):
cfset createobject("component","CFIDE.adminapi.administrator").login('youra dminpw')
cfdump var="#createobject("component","CFIDE.adminapi.runtime").getRuntimePr operty("PostParametersLimit")#"
Curiously, yours came through fine (did you enter yours in the web-based forum interface? I am replying by email), and I see that your code is essentially the same. It worked for me, so I would say that if the value is empty for you, that means it’s NOT defined (in the neo-runtime.xml), which of course it’s not by default in CF 9. You have to add it. If you may feel you did add it, then I would propose you may have added it in a way that it’s not being recognized. You have to be sure to enter the XML just as offered in the technote. It’s best to find the one for postsizelimit, and duplicate it, and then modify the duplicated version.
Hope that helps.
Europe, Middle East and Africa