Interesting post came out today on Coder’s Revolution. It appears that cfcatch is not locally scoped.
I’ve put together what I believe is the Java equivalent of CF’s GenerateSecretKey, Encrypt, and Decrypt functions.
Unfortunately these encrypt and decrypt functions still do not work in CF7 so there must be something else besides the US_export_policy.jar & local_policy.jar files that would need to be upgraded in order to allow for strong encryption to work in CF7.
I’ve posted the code below in hopes that someone will tell me I’ve made a mistake and that we could get this to work in CF7.
The code is based on this article from Sun.
This does not get enough attention.
Out of the box Coldfusion does not have strong encryption and will not generate keys higher than 128 bits. You must upgrade the underlying Java library in order to gain access to strong encryption. Currently the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6 download is located here. Download the file, decompress it, and then replace the existing US_export_policy.jar & local_policy.jar files from your Coldfusion install with the ones that you’ve just downloaded. After restarting Coldfusion you will be able to use the GenerateSecretKey function to create keys stronger than 128 bits.
This has been tested to work with CF8 & CF9.
Replacing the files did not cause errors in CF7, but in CF7 the GenerateSecretKey function only takes one argument which is the encryption algorithm and does not allow for a key length to be specified. Perhaps those of you who know java will be able to access the underlying encryption library directly and still get it to work in CF7?
UPDATE: I tried this and it still seems to not work.
UPDATE: Per Jason Dean’s comment below: for this to work in CF7 you need to use a different library. The strong encryption library for CF7 can be downloaded here.
Today I was going through an application turned over by a contractor and I began noticing that evaluate() was used frequently through out the code.
I thought by now we’d all know that using Coldfusion’s evaluate() function should be avoided. Evaluate() is a performance hit and is an indication of sloppy code. It may be possible that there are situations where it is unavoidable, but in my experience if you are considering to use evaluate() to solve a problem its a red flag that there is a better solution if you just think a little longer.
With Structures it is easy to avoid using evaluate() as you can dynamically create the struct key such as:
Queries are not much different than structures. The trick is that you’ll need to explicitly define the current row. This is something that is normally implicit.
Dynamically declaring function calls is a neat trick. The example code is a very (very) basic generic getter function, perhaps utilized within onMissingMethod(). Given any string it will try to call a getter function for that property. There is no other syntax to create this call. But using evaluate() should be a red flag. When you get into a situation such as this you should really ask yourself why you are organizing your code this way.
Perhaps you could forgo building a named function for each property and restructure your generic getter function to work like this:
or possibly even simpler as:
You should definitely be asking yourself why you would call a generic getter function if you built named getter functions. (Maybe you’ve made the methods private?) This is a simple example, but either way evaluate() is most often a sign of a larger coding problem.
Brian Rinaldi over at RemoteSynthesis.com contacted me today and told me something that got me pretty excited. Evidently Mura CMS uses my AnythingToXML as part of its core requirements. I had to download Mura and see for myself; it does!
From the stats on RIAforge I can see that a few people have downloaded AnythingToXML but I never know if it worked out for them. Its great to see something that you built to get you out of a jam taking on a life of its own and helping other people out.
I have yet to work on a project using Mura, but from what I hear its a great content management system and is developer friendly. Hopefully I’ll get a chance to work with it soon.
I spent some time updating AnythingToXML last month with a feature that allows for type hinting. I was trying to avoid this, but XMLToAnything really can not be made smart enough to know that something was once an array with only one element in it. Instead it will interpret it as a Coldfusion struct. Since XMLToAnything was written to reverse XML created with AnythingToXML I added the type hinting to the XML generation. If there is no type hinting it will still work as before and attempt a best-guess on what the XML should become.
If you’ve been following along I’ve been trying to track down why some JPGs create errors when using CFIMAGE but most JPGs do not.
The work around I posted previously still did not work for some JPGs.
Looking back at the error reports I received a co-worker and I noticed that most of the errors came internationally from one locale. When we contacted that office we discovered that they were using MS Paint to edit and save their JPGs before uploading them. Switching them over to using MS Office Picture Manager to save the images made everything upload correctly.
I’m not sure if the bug is with MS Paint, Coldfusion, or the underlying Java, but if you’ve done everything and still are getting an error when working with images in Coldfusion (or Java?) then checking the source of your images may be be helpful in debugging.
Did anyone find MS Paint to be the root of their JPG image problems?