From Aaron:

"By putting the user in the session scope you would not have to pass in the session to any of the methods in your security class, right?

Example:
<cfset session.siteuser =
application.siteUser.getAuthenticatedUser(username,password) />

I kind of thought that Kevan’s idea of passing in everything in the session scope was a little strange, but perhaps I am not getting it."

Yes, I think Aaron is right.

From Peter:

"Well, I’d probably do something more like:
<cfset session.SiteUser =
attributes.UserService.getAuthenticatedUser(Username,Password)>

This assumes you are in some kind of cfc that has has the UserService injected using ColdSpring or LightWire via constructor or setter injection."

Many thanks, Peter.

I would put the changePassword() into the SiteUser, but I’d actually delegate to something other than the service layer. I think it is very easy to get into "OO Procedural coding" where we have class libraries (service classes) and fairly dumb TOs. Because of that, I try to limit service classes to handling collections of business objects or acting as a factory to return the business objects based on a query. Once I have a SiteUser, I’ll either let it do the work, on in the case of authentication I’ll compose it of SiteUserSecurity.cfc or something similar (still playing with exact naming and functions) to handle that rather than running everything through a service method.

Hi Peter, thanks very much for your comments. I have also copied some of your notes from CFCDev:

"I actually think some of those could go into a session based SiteUser object – I typically put operations into a service method only if they relate to a collection of objects or if an object instance doesn’t yet exist (in which case the service method or the DI engine has to handle it – one of the two). Because that seems to me object specific, for know I put such code into the service method rather than a generalized factory. For example, I’d put changePassword() and hasRole() into the SiteUser business object. Not always the right approach, but not a bad generalized solution."

Would it make sense to have a reference to the security service stored inside the SiteUser object, and have a call on siteUser.chancePassword() (for example) delegated to the securityService.changePassword()?

Hi Aaron, for your encryption you could perhaps use the built in ColdFusion hash() function. I have not used this before, but it may be just what you need. Alternatively try a search for ‘one way encryption coldfusion’ and you should get some links. See the following link for some info on encryption and the hash() function: http://www.adobe.com/devnet/server_archive/articles/understanding_encrypt.html

Firstly, I’d use ColdSpring (or LightWire when it’s ready for primetime :->) to handle injecting this into any controllers that require it rather than just sticking it in application scope. Maybe not a big issue for this one component, but it’ll become more important over time.

Secondly, it is fundamentally users that are being authenticated (at least in this case), so I’d give the responsibility for this to the UserService and then just delegate the responsibility to UserAuthenticationService – I think that’d be cleaner.

I’d also take a more OO as opposed to service level approach. A lot of the features you put into a service singleton I’d put into the a SiteUser.cfc business object that would probably be stored in session scope (assuming you were using sessions) – again delegating to a UserSecurity or UserAuthentication object as it’s generally a good idea to put responsibilities into the business object rather than a service layer where possible.

Just some thoughts which I guarantee to be worth exactly what you paid for them :->