Critical-Web

Yesterday we looked at how to setup a login form and process the information with ColdBox. Today we'll go a step further by viewing the code behind the authentication model.

At the very beginning of our processLogin event we called upon the authenticationService object to, well, authenticate the user. The authentication model is made up of three distinct objects: authentication.cfc, authenticationService.cfc and authenticationGateway.cfc. The authenticaionService is the main entry for all requests to the model. The gateway is the part that interacts with the database. Authentication.cfc is basically just a bean that gets passed around alot.

authentication.cfc

Basically just a bean, it has a couple of properties and a series of get/set methods:

Nothing too special happening here. The setX methods store the value in the bean's instance so they can be retrieved later with the getX methods.

authenticationGateway.cfc

AuthenticaionGateway is the main entrance to our model. This is the object we request from ColdSpring in our processLogin event.

Our first method, init(), is going to be called by Coldspring to set the gateway automatically. The authenticate method is the one we call when we want to confirm that the entered user name and password are correct. The way we achieve this is by instantiating an authentication object and then passing it to the gateway for processing. We then return the processed bean to the requester.

The final method, isAuthenticated(), is a way to encapsulate the logic behind testing for successful authentication. The processLogin event doesn't need to know the rules behind a proper login. It just needs to ask the service by passing back the bean. The service knows that if the user_id isn't 0 and that there were no errors the authentication was a success.

authenticationGateway.cfc

This object is really simple and contains only two methods: init and authenticateUser.

As before, the init method is called by Coldspring to properly initialize the object. We configured our coldspring.xml.cfm file to pass in the dsn parameter to the authenticationGateway object, which it does supernaturally. The authenticateUser method is where everything happens. Basically, it queries the database with the bean's user name and password properties.

I built my query this way so that with a single cfquery tag I could confirm the user name exists even if the password check fails. The first table (name) will have a record if the user name matches. If not, the entire resultset will be empty. The second table (pw) will only have a result if the password matches as well. The CASE clause checks for the existence of a record in the second table. If a row is found, it returns 1 (true). Otherwise, it returns 0 (false).

The second part of the method sets the user_id or the error, depending on the situation:

• If there are results and
  • the password is correct: the user_id is set;
  • the password is incorrect: an error is set ("INVALID_PASSWORD");
• If there are no results: an error is set ("INVALID_USERNAME");

Why go through all this?

You might be asking yourselves: why go to the trouble of doing all of this in the first place? Sure, I could've put that query right in the middle of my processLogin event and checked for the logic there. There are a couple of good answers to that (I hope!).

Encapsulation of logic

Best practice dictates that a controller of an MVC framework should do as less as possible. It's a traffic agent. It doesn't need to know how the cars run, it just has to know how to get them across the intersection without causing an accident. Getting our authentication logic out of the controller and into it's own model allows us to separate concerns and keep logic where it needs to be.

Reusability

What if our processLogin isn't the only one that will need to handle authentication? There might be other reasons to call upon the authentication logic: web services, different frontends (Flex, among others). If we have all of our login code in the controller we need to copy it to every event that needs to check for authenticaion. Our authenticaion code is also pretty generic. We could very easily copy it over to a different object, validate the query is still valid against the different database and we're set!

It ain't that complicated!

At first glance, it does look complicated. There are three .cfcs where a query and a couple of lines would've done the trick. However if you look closer you'll notice that there really isn't that much going on. Some generic set/get methods, another one for querying the database and two more for authenticating the user and making sure the authentication was a success. On top of that, the code within the controller is much simpler. All it needs to do is ask the authenticationService to do the heavy lifting.

I hope that clears it all up. One of the nice bonuses of our authentication model is that, although it relies on the users table, it isn't built from it. We couldn't use Illudium PU-36 Code Generator to generate our cfcs for us, we needed to write them on our own. I feel this helps to understand the relation between the different objects in our model. In most cases, however, our models are built from database tables so most of the code can be generated rather simply. All we need to do after is query them from our controllers and we're set!

This entry was posted on August 4, 2009 at 9:20 AM and has received 2112 views. There are currently 0 comments. Print this entry.