CFCs and the Single Web Developer
Didn't all the talk about CFCs go out in the early nineties? Isn't a CFC some nasty chemical compound that chomps on the ozone layer? Well, that used to be what we defined a CFC as, but since ColdFusion MX, a CFC is a reusable module of code that we can write to change the value of strings, perform query operations on a database, write a trigger for a stored procedure, or really anything our code hungry little brains can think up. The need for CFCs developed once enterprises began to want to build object oriented web applications. ColdFusion originally had been developed to be easy to learn and use, so it was a procedural language similar to basic. The code executed as it was written so it was relatively easy to read through a block of code and see what it did.
ColdFusion is still procedural, however through the use of CFCs(Cold Fusion Components) we can simulate object oriented design. The proper use of CFCs starts way before we write even a single line of code. In the planning stage, a web developer has to ask themselves, “does this need to be a part of every web page?” “Can this function stand on its own, and would it be cool if I could use it for all of my applications?” If the answer to the first question is yes. Then you should probably just put the code into your Application.cfm file. If the answer to the second question is yes, then we should start looking at building a CFC to handle that function.
Building a CFC really requires that you understand three tags. The cfcomponent tag, the cffunction tag, and the cfinvoke tag. The cfcomponent tag is a wrapper for all of our cffunctions. The cffunctions will be doing the work for us. You can include as many functions as you would like inside of your cfcomponent wrapper. You can even have a function call another function inside of the cfcomponent wrapper, or another cfcomponent. When you save your file, it has to have the extension .cfc or ColdFusion won't know that it contains components, and your cfinvoke won't work. One of the cool things about components is that you don't have to cfinclude them to make them work. Thats what the cfinvoke tag is for.
So let's dive right in. The problem is that our application needs to have a login page, and every page in the application needs to verify that the person reading the page is indeed logged in. Easy right. So to plan it out quickly, keeping display, data, and logic separate, we would have a form that takes user input. Then a second page that invokes our login verification, to check if the username and password are correct (this is a simple login system), and a third page that acts as one of the many pages of the application that will indeed verify that the user looking at the page is logged in. You will have to make sure that session variables and the proper timeout is set up in your Application.cfm file for all this to work. I am going to assume that the people reading this article know how to create a form that when submitted passes the form values to a file called validate.cfm. Our CFC file is called security.cfc. Here is the code for our password validation function:
What this code does is to take the arguments supplied by the cfinvoke tag and pass it over to the cffunction. Once the function gets the username and password arguments, it checks them against what is stored in the function. If they match the function returns true or false back to the validation.cfm file. Where the following code decides what to do with it.
what the above invoke does is that it calls the passwordAuthentication method we created in our cfcomponent in the file security.cfc in the same folder as the validation.cfm file, sets the return variable of true or false to the ColdFusion variable gonogo. The remainder could be another function, but it is so little code that it seemed like overkill to make it one. The cfif statement checks the value of the variable gonogo and if it is true it creates a session variable named authenticated to true and passes the user on to the application. If gonogo is anything but true it will pass them back to the login page.
The next step is to write a cffunction to check to see if the user is logged in to provide security for each page. The cffunction can go into our security.cfc file. It would look something like this:
This function checks the session variable authenticated to see whether it is set to true or not. Based on your cfapplication settings it will timeout and force the user to log in again. If the variable's value is true then it will do nothing and let the user see the page, however if it has timed out or the user has tried to improperly access the page it will send them back to the login page.
There is now one last thing to do. To make sure that every page of the application calls this CFC to make sure the user is logged in. This can be tricky, because you could create a bad loop where as soon as the user tries to log in, the page goes back to the login page, repeatedly. If you put the cfinvoke into your Application.cfm file then it will constantly loop. The way I resolve this is to put the cfinvoke tag into each page of the application that I want protected, leaving it out of the index.cfm page, or the login page. There are more creative ways to do this, but it really is only a couple of lines so it isn't a big deal. True purists would do something more dramatic, but I like to get things done, and for a small application this is sufficient. If however, you have a larger scale application you would be best served by making your authentication stand alone. The code for the start.cfm page and all other pages of your application would be like so:
That's all it takes. I hope this helps some of the CF developers out there that want to get into the world of CFCs. It really fires the imagination, and can help reduce the alarming failure rate of custom developed applications. Good hunting!