500 error in IIS7 with ColdFusion and huge form posts or coldfusion.filter.FormScope$PostParametersLimitExceededException: POST parameters
Last night I was bitten by exceeding the parameter limit on form posts with Coldfusion (9.02), here within abbreviated as ACF. Basically if you installed the 9.02 CHF 1 or installed security hotfix APSB12-06 on an earlier version of ACF, it will restrict your form post to 100 fields. Why they think this is a good security measure is beyond me, but that’s what it does
Anywho, the issue is that you OBVIOUSLY know don’t if you’re going to run into the 100 field limitation until your clients start calling you because they are receiving a 500 error. The bad part about this, is that the error happens at the IIS level so the request never even gets to ACF, hence you wouldn’t receive an error email from ACF if you had that setup (you do have ACF emailing you when errors occur, correct?)
The work around is simple though, and is described in another security hotfix (APSB12-15). Basically you open the neo-runtime.xml file, find the following line:
and add the following right after itL
BTW, you can make that number whatever you want. I choose 10,000, because well, why not.
Then restart ACF and everything should be cool… right? WRONG!
Even after I did this, I still got the 500 error. After like an hour, I decide to open up the neo-runtime.xml file again and did a search for `postParametersLimit`. Guess what, not only was the line that I added in there, but there was a second instance of the line somewhere in the middle of the file. Now I didn’t put it in there, so I’m wondering if maybe it was included in the ACF 9.02 version I downloaded already. Whatever. I just removed the second instance and everything is working now.
You might get this error when trying to manipulate a photo with cfimage (such as resizing). I got this when trying to do exactly that with a JPEG.
In order to get around this error, I opened up the photo in a photo editing program and saved the photo as a BMP. Then I opened up the BMP in the photo editor and saved it as a JPEG.
railo is a great alternative to adobe’s cfml server, but there lets face it… it’s a pain in the ass to get configured on iis6! rather then have you fight through all these errors, i’ve documented the errors that not only i encountered during the setup, but also was able to create. hopefully this will save you from getting frustrated.
the following errors may happen when installing railo on IIS6 and visiting the site. (note: all paths assume that you installed railo to the c:\railo directory)
Error: Invalid function
Cause: This happens when you haven’t chosen to install the iis connector or something screwed up in the installation of the iis connector. you can see this if you go into the C:\railo\connector\isapi_redirect-1.2.31.properties and you see @@install_dir@@ in the file. those markers were suppose to be replaced with the directory you installed railo.
Fix: don’t just try to change these markers to the installation directory as they aren’t just in this file. the best bet is to run the installation again and make sure you check to install the iis connector.
Error: The system cannot find the path specified.
Cause: you forgot to configure the jakarta virtual directory for the site in iis.
Fix: go into iis and add a virtual directory called “jakarta” to the site experiencing the error. make sure to point it to the c:\railo\connector directory. Make sure to give the virtual directory “scripts and executables” permissions.
Error: You get prompted to download the cfm file
Cause: you forgot to give the jakarta virtual directory “scripts and executables” permissions.
Fix: give the jakarta virtual directory “scripts and executables” permissions.
Error: you get a 404, page not found error (from IIS)
Cause: you have not allowed unknown cgi and isapi extensions in IIS
Fix: click on the web server extenstions folder in iis admin. allow both unknown cgi extensions and unknown isapi extensions.
Cause: this could also be because the application extension aren’t configured for *.cfm extensions.
Fix: the railo installation instructions forgets to mention that you need to configure the site with application extensions for *.cfm extensions. go into the properties for the site and click the “home directory” tab. next click the “configuration” button next to where the execute permissions drop down is. on the next page, click the “add” button under the application extensions section. for the executable, browse to the isapi_redirect dll located in the c:\railo\connector directory. for extension, enter in *.cfm. uncheck the “verify that file exists” checkbox. repeat this process for *.cfc if you site uses components.
PROTIP!!!!: if you want you can configure all the sites and future sites with these application extension by right clicking on the “web sites” folder and following the instructions above.
Error: you get a railo missinginclude error
Cause: you have configured the host section of server.xml wrong
Fix: most likely the cause is when you have misspelled an alias. make sure that all the aliases are spelled correctly and that the host section is configured properly.
Error: Unspecified error
Cause: you don’t have the isapi filter configured for your website.
Fix: the installation instructions for railo forget to mention that you need to configure an isapi filter for the website in order for railo to work. go into the properties of the site and click on the ispai filter tab. add a filter called “railo” and for the executable, point it to the isapi_redirect-X.dll located in the connector directory. so for 3.3.1 the path would be c:\railo\connector\isapi_redirect-1.2.31.dll.
when running the cfwheels test suite under oracle you encounter the following with Railo (maybe also with ACF)
Problem: ORA-04098: trigger ‘WHEELSTESTDB.BI_USERS’ is invalid and failed re-validation
Solution: no whitespace can be in the cfquery tag.
This will cause the error:
<cfquery name=”loc.query” datasource=”#application.wheels.dataSourceName#”>
CREATE TRIGGER bi_#loc.i# BEFORE INSERT ON #loc.i# FOR EACH ROW BEGIN SELECT #loc.seq#.nextval INTO :NEW.<cfif loc.i IS “photogalleries”>photogalleryid<cfelseif loc.i IS “photogalleryphotos”>photogalleryphotoid<cfelse>id</cfif> FROM dual; END;
change the cfquery to this:
<cfquery name=”loc.query” datasource=”#application.wheels.dataSourceName#”>CREATE TRIGGER bi_#loc.i# BEFORE INSERT ON #loc.i# FOR EACH ROW BEGIN SELECT #loc.seq#.nextval INTO :NEW.<cfif loc.i IS “photogalleries”>photogalleryid<cfelseif loc.i IS “photogalleryphotos”>photogalleryphotoid<cfelse>id</cfif> FROM dual; END;</cfquery>
add the following arguments to the "Server Settings > Java and JVM" in the Administrator -Dhttp.proxyHost=proxyhostURL -Dhttp.proxyPort=proxyPortNumber -Dhttp.proxyUser=someUserName -Dhttp.proxyPassword=somePassword
I think I was shot down within 3 hours. No debate, no nothing :p
If you haven’t heard by now, there is a huge security vulnerability using cffile to upload files. This effects every CF application out there and is being exploited as we speak. There is a ton of information out there about what causes and how to perform the exploit, however noone is doing anything about it at the moment to fix it. Needless to say, I wasn’t going to just sit by and wait for someone to fix it, so naturally, I came up with a pretty slick solution on my own. Below is a link to download a UDF that you should be able to use as a replacement until this whole thing gets sorted out.
If you have any comments on improvements or suggestions, please leave them below or feel free to edit the gist directly.
Well Day3 and 4 ended up with me having to do client work and some work for my day job. Those two days were a bust and I should of ended the days with doing some more coding, but afterwards my mind just wasn’t into it. I’m learning that this wasn’t the smartest idea. I now see why it takes a long time to get things done.
On top of all that, while I was just sitting down to type this out, I saw that the two commits to trunk that I made today weren’t the smartest changes either and I was asked to revert them, which I did.
I think I’m going to take a break tomorrow from testing and trying to find bugs since I basically creating my own 😦
Wheels was donated some migration code quite a while ago from Ryan. One of my goals this weeks was to try to get migrations working. I figured tomorrow I fork the my local repo and see what I can do to get this in.
Today was WAAAAY more productive then yesterday, way more, even though I went to bed at 6:30am this morning. I had to finish a project for a client and decided that I better get it out of the way before it started to haunt me and dip into my Wheels time.
The entire day was spent revamping the testing framework for the last time (I hope) as I think I finally got it to where I want it to be. I did a bunch of optimizations to the testrunner and the output display. In doing so I discover the beauty of getComponentMetaData().
When running the tests, I had some logic in place that basically would inspect the meta data of the component you wanted to test to see if it is extending the wheels.test base component. There’s no reason to even waste the time searching for tests to run if the component won’t even have any and the only way it’s going to have tests is if it extends the wheels.test base component.
In order to do the check I would use createobject to create an instance of the component and then use getMetaData() to inspect the meta data. To me this seemed kinda dumb and it bothered me that I knew there had to be a better way and that’s when I found getCompoentMetaData(). Basically this does the same thing as getMetaData() but you don’t have to waste your time instantiating the component. All you have to do is pass the component path to getComponentMetaData() and it does the work for you and returns the exact same meta data that getMetaData() would. Very handy function indeed.
The other thing that was bothering me was the hackery way I was altering the application.wheels.modelPath and the application.wheels.modelComponentPath so that I could call test models with the model() function. Before I was performing my half ass hack inside the test cases themselves in the setup(), but I knew that this was going to get messy. It finally dawned on me to just add them into the testing framework itself for now. Later on we’ll think of a better way to pass a component path to model(), but as for right now this prevents me from having to do the hack manually and even though it’s still a hack, it’s a bit cleaner.
After finally getting the testing framework ironed out, I moved on to refactoring all the tests to get more output and separate the multiple calls to assert() I was doing in each test. All and all, Wheels not has 61 tests in 19 cases. Not bad for a start. It’s definitely NOT where I wanted to be at this point, but there’s no sense in rushing either.
Tonight I ‘m going to do some research into designing a testing database that I can use to properly test the model layer. I’m sure I’ll be totally OCD about the way it’s designed and will spend most of the day second guessing myself over and over. One of the ideas to get around this was was to look at maybe using the blogCFC database since it’s already been ported to like EVERY RDBMS engine out there (go Ray!). We’ll have to see.
Will update again tomorrow.
So how is it going so far? HORRIBLE!
Well first off, I updated my cygwin install with the latest version of git and subervion-perl a couple of weeks ago and when I went to rebase with the CFWheels repo, it would die. Only one commit at a time would be pulled down and then errors all over the place. After searching on google I found out that this is a known problem with the latest subversion-perl so I had to downgrade. That took me about an hour to figure out. I could have applied a patch to the version that I had already installed, but I wasn’t in the mood to be jerking around like that and I figured I’d leave that stuff to the experts.
After that I was finally able to sync with the svn repo and get everything up and running.
With my confidence in the toliet, I started writing tests and finding bugs that needed to be fixed. When I found my first bug, I decided to use trusty old tortoisesvn to write the patch and get it into trunk since I had local checkout already. That went well, but it wasn’t the best way to do it. I should be using git and git-svn to do this stuff and by using tortise I had to litterally duplicate the patch that I already had in git. NOT SMART!
Anyhow, I continued coding and soon found another bug that needed some attention. “WHAT LUCK!” I thought because now I could submit the patch through git-svn like I should have been doing all along. BIG MISTAKE! Let’s just say that I fought with this for almost two hours, because I kept screwing up the workflow left and right and having to git reset –hard. Thank God that stackoverflow.com exists and after reading carefully, the solution that I found, and some playing around, I finally got the workflow down and was able to commit the patch.
All and all, I’m having a rough time. Maybe I’m just off my game today since I have a lot of other things in my head right now and my mental state isn’t in sync. No matter, tomorrow is another day and more coding.
Tomorrow I’m planning on completing the creation of a test database so that I can test out all the functions that depend on models and cleanning up the tests.
About the tests. Right now, the way I’m writing tests, I’ll have more then one assert in each test. From what I’ve seen and researched how other people write tests, this is the wrong way. You should have one assert for each test. After writing a bunch of them, this makes sense. Reason being is because if you have 5 asserts in one test and one of the asserts fails, the whole test fails. Now currently this isn’t a problem because I know it’s the last assert I wrote that failed. However, down the road I can see this becoming a problem when we’re trying to figure out where the test is failing. It’s not like I want the rest of the team to be commenting out asserts until they find the one thats failing. I come to the conclusion at this point that I’m going to have to rewrite all the tests I’ve created into this new format. Oh well it’s what learning is all about and the reason I love doing open source stuff.
I’ll update again tomorrow.