The SmartCard SSO rewrite is nearing the end of the testing phase and there are several packing issues being worked through. Now is a good time to talk about what all has happened during this rewrite.
The primary goal for the SmartCard SSO rewrite was to reduce or eliminate scope locking conflicts and problems we were experiencing in the use of the application scope. The test period as near the end and I can report that we were successful. SmartCard SSO is a much more reliable product, and easier to maintain because of the following approaches:
Reduced use of the Application Scope: Using SQL's substring we now load everything from the requested module's settings table that we need into the request scope. In fact the application scope is only used as a place holder for very few things that get loaded into the request scope in OnRequestStart. CFC's are initialized in OnApplicationStart and a minimal amount of variables are set there and then in OnRequestStart, they are copied to the request scope.
Use of CFCs and a more object oriented approach: All queries are now in DAO_SSO.CFC and the rest of the logic is in SSO.CFC. DAO_SSO is not really a DAO in any strict sense but that was an easy name to use to identify it as the data part. Both of these CFCs are local to the SSO application. Everything is heavily commented.
All that said, we still have one goal to finish and test--passing querystrings through to modules--and some challenges in packaging to resolve.
Over the course of the rewrite, we made several needed changes in PIMS overall that ended up being incorporated into SSO. One of these was the incorporation of a library of CFCs that are global to PIMS. Currently it houses Security, Email, Utility, Calendar and Server methods. Some examples of the methods in the library are email validation and error handling, string encryption and decryption, and some querystring handling. This all needs to be packaged up with SSO because it is called by every module including SSO. We place our library into a CFC folder at the root of the site, but not everybody uses a CFC folder. Those that do may have already started their own library. So this will all have to be addressed in some documentation for the library and I will have to decide whether to package it separate from SSO or as a part of SSO. I'm leaning toward a separate package.
We have already started moving beyond the PIMS Library of CFCs and are experimenting with ColdBox and a new authentication and role management scheme that we intend to apply to any new work. This will eventually replace SmartCard SSO and be much more robust.