So, at the office we've been developing on top of ColdFusion 8 for a while now, testing our code so that we know we'll be safe to officially migrate to 8 when we migrate to our new datacenter. Last week we actually set up one ColdFusion 8 instance within production, to place inside our load balanced environment, to judge true application performance under load. During the setup, and before placing it into the mix, I use the localhost hosts file to direct specific sites to the localhost for testing. This has always been helpful in the past, and this time was no exception. We fired up the services, hit one of the sites, and it all promptly broke.
There's nothing like a ColdFusion Error on your very first server page load. It's always best to get trouble out of the way right up front, rather than a creeping issue down the line. This particular error was really interesting, in that it had never shown up within our development environment, making it very unique.
I had a pretty good idea ahead of time, but I turned on Robust Exception Information to get the full skinny. We have a template, that runs only in production, that runs a <cfexecute> tag to allow certain resources. This has an encrypted value, pulled from the database, that uses the Decrypt() function, with the value originally encrypted using the Encrypt() function on a ColdFusion MX 6.1 server, many moons ago. We did not have an issue with this under ColdFusion MX 7, so this was a little perplexing. I pulled up the ColdFusion 8 function documentation, so that I could review the required arguments, but I could not find anything there to answer why the code was giving me an error.
OK, so now it was time to experiment a little. I pulled up the documentation on the Decrypt() function for versions 6.1, 7, and 8. Versions 7 and 8 both had needed encryption improvements, bringing new arguments to the function. The 7 and 8 documentation both said that the new arguments were optional, and for 7 that appeared to be the case, but with 8 I was going to have to play a little. The first thing I noticed was the new algorithm argument, which was supposed to default to CFMX_COMPAT (three guesses what that means). I tried this argument on my 8 configuration, to no avail. I then read further, concentrating on the encoding argument. IVorSalt and iterations are two other possible arguments, but I couldn't see either of these applying to a value encrypted using 6.1.
Not knowing which encoding was applied through the default 6.1 Encrypt(), I decided to apply more time to the encoding argument, I decided to try some of the values to see what might work. I tried Binary first, but still received the error. Next I tried Hex, which finally gave me success. In the end my statement look something like this:
Maybe, if the value had been encrypted with ColdFusion 7, it might not have required the additional arguments. But, since it had been encrypted using 6.1, it was necessary to clarify for ColdFusion exactly what was needed. Hey, lessons learned.