Page 1 of 1 We've all heard this question over and over again the Dreamweaver forums: "Why won't the User Authentication server behaviors work in my ColdFusion site?". The reason is that you have to enable sessions using a file called "Application.cfm". Some would see that as a fault in ColdFusion. I disagree completely. Why waste server resources to allocate space in memory for information that might never be needed? If you need them, enable them; if not, don't.
This article will show you how to enable sessions for your ColdFusion application.
It is a good idea to always use a capital "A" when naming your "Application.cfm" file. While it isn't necessary on a Windows based server it is required on *nix servers.
Once you have created your Application.cfm file, you will need to place some code on the page to tell ColdFusion what to enable and how long they should persist. We do this using the <cfapplication> tag. Below is a table of variables available to the <cfapplication> tag.
At its most basic, your <cfapplication> tag should have the following elements:
With the above in mind, here is a basic implementation of the <cfapplication> tag:
<cfapplication name="myApp"
sessionmanagement="yes"
sessiontimeout="#CreateTimeSpan(0,0,20,0)#">
First we give our application a name using the name attribute.
You might think this isn't very important, but think again. There are uses for the name attribute, especially with ColdFusion MX's new ability to lock at the application level. By that I don't mean lock an application variable. I mean the ability to lock a variable within a specific application.
Next we enable session variables by setting the sessionmanagement attribute to "yes". Finally we tell ColdFusion how long the variables should be active. In the above example our sessions would persist for 20 minutes.
To establish how long session variable should remain active we use the CreateTimeSpan function. The CreateTimeSpan function works by taking the values within parenthesis (formatted as days, hours, minutes, seconds) and doing what its name implies.
That's really all there is to enabling session variables in ColdFusion. Once completed your User Authentication server behaviors should work just fine.
I can already hear the next question. Why doesn't Dreamweaver create this file for us when we use the server behaviors? Well, remember at the beginning of the article, when I said you might want to include other things in your Application.cfm page? That's why. Let's say you used the server behaviors to create a log in form on a page in your site and Dreamweaver created the Application.cfm file for you. Then you added some things to that Application.cfm file. Now you need to have another section of site password protected so you create another log in form and use the server behaviors to authenticate that form as well. Oops! Dreamweaver just recreated your Application.cfm and now all your changes are gone. Wouldn't be very fun would it? From the right perspective it is a good thing Dreamweaver doesn't do this for us.
One thing that should be pointed out is the fact that there are issues with sessions when used in a shared hosting environment for advanced web applications such as shopping carts. For example, if you are using a shared SSL for your cart and the host maps those requests to another IP, your sessions would not follow. This would be a problem. Look for an upcoming article by Lawrence Cramer entitled "CF Sessions in Shared or Clustered Environments" that will address these issues.
Using the "Log Out User" server behavior will, in effect, log your visitor off the site. It doesn't, however, actually kill the sessions. What is does is set the appropriate sessions to blank, or null, values. So how do actually kill the sessions? Simply use the following code to delete the ColdFusion structure that contains the user's log in information.
<cflock timeout="5" throwontimeout="No"
type="exclusive" scope="session">
<cfset tmp = StructDelete(Session, "loggedin")>
</cflock>
Let's see what is going on here. First, and foremost, be sure to lock the session. While improvements have been made in ColdFusion MX to prevent corrupting session data, in older versions is a highly recommended practice. Next we actually delete the user's session structure using the StructDelete() function. To do so we first tell the function what type of structure we want to delete (session in this case). Then we tell it what structure to delete (loggedin). And finally we unlock the session by closing the lock.
The session used above is an example only. If you used the Dreamweaver server behaviors to authenticate your visitors, you will have multiple session variables with names other than "loggedin".
As you have seen enabling session variables in ColdFusion is easy, even if it isn't automatic. I'll leave you with a "food for thought": The Application.cfm is automatically included in every page and can include more than just the <cfapplication> tag. Maybe this page would be a good place to put other pieces on information that will be needed on every page within your web application? Hmm.....
While you can include more than just the <cfapplication> tag in your Application.cfm page, it is recommended that you NOT put any HTML code in this page. You can however <cfinclude> some HTML code.
Page 1 of 1 1
Keywords
ColdFusion, Cold Fusion, sessions, session management, user authentication.
