Tuesday, November 26, 2013

ESAPI4CF v1.1.0 released!

A new minor version of ESAPI4CF is now available!  I decided to increment the minor version this go around because there were several significant changes included so it seemed appropriate.

The full release notes can be found here: https://github.com/damonmiller/esapi4cf/releases/tag/v1.1.0a.

The ESAPI4CF API documentation and tutorials have also been updated: http://damonmiller.github.io/esapi4cf/.

First thing I'd like to point out is that I finally took the time to learn a little more about GitHub and found out how to tag and define releases.  So v1.1 marks the first release that shows under "Releases" on the GitHub project.  Sorry, but you probably don't want v1.0.x anyway since there is some good stuff in this release including some important bug fixes.  Version history won't be an issue moving forward now that I "git" it. :)

Now only 1 line to init ESAPI

Previously, you had to init the main ESAPI component then make a separate call to tell ESAPI where you resources folder was located.  I've combined this into a single call so you can now pass the resources folder location into the ESAPI init.  The 2 lines for init was annoying me so I imagine others would feel the same.

You can still make the 2 line init in v1.1 and it will continue to work as before or use setResourceDirectory() if you need to change the location later on.

Encoder is now ESAPI4J dependent

Not sure why I didn't do this sooner.  I just think it never clicked before.  I think I looked at so many articles on people using the encoders from ESAPI4J enough times where it finally just occurred to me, why am I not doing that?  ESAPI4CF is dependent on ESAPI4J for several things, why not the encoders?  Let Java do the heavy lifting and we get a small performance improvement per encoder call.  Win-win if I do say so.

JSESSIONID cookie now has HttpOnly and Secure set

This one is in the ESAPI specification but ESAPI4CF was just not doing it correctly until now.  Railo and CF10 can do this and CF9 can set HttpOnly but if you wanted Secure in CF9 or either attribute in CF8 you were out of luck previously unless you knew to use Java to override the cookie.  Now ESAPI4CF takes care of this for you and it does it without any additional calls.  It is part of the initial request/response registration using setCurrentHTTP() so no changes required on your part to take advantage of what should be a requirement in any modern day web application.

Password strength now fails if it matches the accountName

This was an addition to the ESAPI v2 specification but I added it now because it is an important one to have.  Your password cannot be the same as your accountName - enough said.

Internationalization support for isValidNumber/getValidNumber

I am big on I18N support (probably because this is one of my main responsibilities at work) and ESAPI4J severely lacks in this department.  This is the first of several changes I will be making to ESAPI4CF which deviate from ESAPI4J around I18N support - the other changes will involve resource bundling for translations.  I added an additional required argument to the isValidNumber and getValidNumber methods to provide a number format instance to use to parse the input.  This allows you to pass in localized numbers that can be parsed and you will get back a numeric object.  The date validator methods already supported a format argument which provides the identical functionality - why this was never added for the number validators is beyond me.

What I really like about the "format" argument approach for both date and number validators is you can use the default Java formatter instances if you choose or if you are like me and prefer ICU4J, you can pass those formatter instances as well and it works just the same.  Well it actually works better because ICU4J is just better. :)

The other number validators, double, integer, etc, were not altered.  If you are dealing with localized numbers you should call the getValidNumber validator first to get back a numeric object then call the appropriate numeric validator for your scenario.  Just FYI, the getValidNumber method already does call getValidDouble after it parses the number so a separate call is not necessary.

SafeFile now supports all the Java File methods

I believe this just got missed the first go around.  SafeFile is supposed to be a CF representation of the ESAPI4J SafeFile which extends java.io.File but the native Java File method wrappers were never implemented.  These now all exist.

Conclusion

So those are the high points of this release.  There are some smaller items as well plus several important bug fixes so check out the release notes for the details or better yet, just download ESAPI4CF and check it out yourself.  I am trying to make ESAPI4CF as easy to understand and implement as possible but it takes community feedback to get there.  Help is always appreciated!  Thanks!