The Largest Repository of ColdFusion Knowledge in The World for More Than 12 Years

ColdFusion on Ulitzer

Subscribe to ColdFusion on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get ColdFusion on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


CFDJ Authors: AppDynamics Blog, Michael Kopp, Tad Anderson, Bob Gourley, Jayaram Krishnaswamy

Related Topics: ColdFusion on Ulitzer

CFDJ: Article

Session States Without the Session

Session States Without the Session

Discussions have centered around clusters and shared sessions: How do you overcome the problem of being unable to share session variables across clustered servers? Why else would you build a sessionless site?

The answers may surprise you. This article documents a technique that allows session states on clustered servers, increases user security, and provides greater development flexibility. However, like all ColdFusion applications, this is only one way to create a "sessionless session," and it can be modified infinitely.

The first answer I came up with when presented with this problem was: "Simple. Use client variables." But how do you create client variables to house data that should expire after a certain time? Also, do users want your session information stored on their hard drive? I don't think so. Besides, it's a huge security risk to store a user's login and session on a computer on the other side of the planet.

The answer? All the data you need is already being set on their machine: CFID and CFTOKEN. For those of you who don't know, whenever session management is initiated, ColdFusion automatically sets the CFID and CFTOKEN cookies on users' computers to track their sessions. This solution does the same thing, just without the session...

Pro's and Con's
The advantages to the CFID/CF-TOKEN approach are endless. By using the CFID and CFTOKEN cookies to reference a user's data, I can store vast amounts of information about a user's session state in an easily maintainable datasource on my server (and no one is the wiser). Here's where CFLOCK also comes into play: you can lock all of your client and session state variables in one area without going to every page that uses them. This reduces the amount of CFLOCKing in general (a time-saver) and the odds of variables being overwritten by other users (a hair-saver).

Naturally, there are disadvantages to this approach as well. What if your user has cookies turned off? You may as well ask what if your site is red and green and your user is color-blind. You can't control this and have no way of knowing about it. However, you can avoid this potential problem by turning the ClientManagement attribute of your CFApplication tag to "no" and meticulously appending the CFID and CFTOKEN variables to every URL, form action, and hyperlink.

The ColdFusion documentation agrees that this is unnecessary: "In ColdFusion, client state management is explicitly designed to work with cookies, the standard tool for identifying clients. Using client state management without cookies requires careful programming to ensure that the URLToken is always passed between applications."

This technique also requires you to perform a small amount of footwork. You must call the appropriate modules each time you want to use a "session" variable. The advantages greatly outweigh this overhead aspect and are easily streamlined. Read on to see how.

Data Storage
Now that you're using the CFID/ CFTOKEN approach, the next question is: How will you keep track of all this data? Technically, you accomplish this by setting client variables, but these variables aren't stored on the client's machine. By setting the "ClientStorage" attribute of the CFAPPLICATION tag to your specified datasource, you can collect all client data in two tables set up by ColdFusion. When you specify a datasource, ColdFusion automatically stores all standard client variables (LastVisit, HitCount, TimeCreated) in the CGlobal table and all user-specified client variables in the CData table.

So how do you store the data? Didn't I just answer that? Yes and no. The data is stored in the CData table. However, you have the option of:

  • Storing each variable as its own row, indexed off the user's CFID and CFTOKEN
  • Wrapping it all into a bundle and storing the data as a BLOB in one row
This is a matter of choice; both are perfectly viable options. I prefer the latter approach for two reasons. First, there's a smaller chance of "losing" users' data by having multiple rows associated with their ID. Second, you may never know all of what's being stored in the client state or how it's named. By storing your information in an often forgotten ColdFusion feature - a structure - you can read and write all of the data without knowing any of the variable names (see Listing 1). To read structure values without knowing the key names, use the StructKeyList function and the CFLOOP tag, as follows:

<cfloop List = "#StructKeyList(SessionInfo)#" index="ThisValue">
<cfset "#ThisValue#" = Evaluate("StructFind(SessionInfo,'#ThisValue#')")>
#ThisValue#<BR>
</cfloop>

Unfortunately, ColdFusion doesn't allow you to set a structure as a client variable. To overcome this obstacle, I used another often overlooked aspect of ColdFusion: WDDX. Simply serialize the structure into a WDDX packet and set the packet as a client variable. When you need to call out your client variables, deserialize the packet and set its name-value pairs as local variables for the calling page:

<cfif IsDefined("Client.SessionInfo")>
<cfwddx action="WDDX2CFML" input="#Client.SessionInfo#"
output="SessionInfo">
</cfif>

I created this feature as a custom tag that's called on any page that sets or reads client variables. If you have a modularized site, you can easily integrate this into your "header" module. With this method you can call any of the stored client variables as a local variable (instead of client dot variable name). If you aren't using modules for your site (you should be!), call the tag each time you want to use the "session" variables. Note: Be sure to use the appropriate attributes and caller scopes if you do implement this as a module.

The Timeout Issue
Finally I tackled the timeout issue: how to automatically log out of a user's session after a given period of inactivity. I built this feature into the same module that deserializes the user's stored data. I simply compared the users' "LastVisit" time with the time at which they logged in. I set the difference to be compared between the login and LastVisit times as an application variable for more flexibility. Since the LastVisit variable is updated with every page visit, the time is accurate. If the LastVisit time is greater than the set logout period, the client WDDX packet is deleted from the datasource and the user is logged out.

Obviously, this isn't the only way to log out inactive users, just the technique I prefer. Other ideas include a constant time check in the header module or Application.cfm. I chose my method because my goal was to decrease the amount of footwork for the other developers on my team and to combine as many attributes into one module call (see Listing 2).

Is This Right for You?
Everyone's site is different. Some sites may not need such an elegant session module when one is already built into ColdFusion. If you plan to scale your site to a clustered environment in the future and don't want to rewrite every page, starting in this style is a safe choice. This technique is ultimately geared toward sites on clustered servers, but can just as easily be used on a single server.

This method of coding will help boost your site's security and give you greater control over your users' session information. Just think, no more "shared sessions," CFLOCK mayhem, or lost sessions due to clustered environments.

More Stories By Tsara Borsting

Tsara Borsting, a Macromedia-certified ColdFusion 5.0 developer, has been programming for five years in Santa Cruz, CA.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.