Make Session Variables Truly Session Variables

Authored July 2000

ColdFusion session variables, if identified by the CFToken and CFid cookies (the default behavior), will persist beyond a browser shut down. Sometimes however, for example if session variables are used to track security status (whether the user is logged in or not), it would be nice if the ColdFusion session actually ended with the browser session.

Explanation

The reason that the session information persists beyond the browser shut down is that the cookies used to identify the session to the server are set as persistent. In other words they have an expiration date and will be stored by the browser until that date. Often this behaviour is desired, but sometimes it's not.

All this code does is force the CFToken and CFID cookies to be set as session cookies instead. (Note that "session" in this case refers to the browser session, not the ColdFusion session.) This means that they are set with no expiration date which tells the browser to delete them when the browser closes.

Since ColdFusion simply needs the values in the cookies named properly it doesn't really matter where the variables are set (in cookies or in the URL; by ColdFusion or by you). Note however that setting these cookies to expire will also effectively kill any client variables that you may have (although there are ways around that, as we'll see).

The Code

The code is pretty simple. First we start by setting the CFApplication tag attribute "SetClientCookies" to "No". This simply tells ColdFusion not to automatically create the CFToken and the CFid cookies. However the thing to remember is that ColdFusion still sets the session variables "CFToken" and "CFid".

You could, as is suggested by Allaire, append these values to the URL to maintain them. We take a slightly different tact and instead use the CFCookie tag to set the variables with no expiration dates, which sets them as browser session variables.

Line six isn't really neccessary unless you need maintain the values for client variables as well. In that case you can use the values in the "CFMarkers" cookie to populate CFToken and CFid. Note however that there needs to be an interim page that sets the session variables since you can't change the SessionID within a template. Also keep in mind that killing the browser cookies does not destroy the ColdFusion session, it only "disconnects" the user from the session. The session information is still in memory using resources until it times out normally.

Uses for this Code

The primary reason for setting session identifiers in this way is to ensure that session information can't be used by somebody that has access to a computer after the original user. If, for example, a ColdFusion application presents personal financial data it would be an unforgivable breach of security to allow somebody to simply open a users browser shortly after they have left the site and retrieve their information.

There really isn't much else that this little trick is useful for. However it may lead to inspiration on other fronts. Session identifiers can be stored in a database, passed via email or WDDX, and, in the case of client Variables, used to create standard "profiles" that could be assigned to end users at random. We are currently working on a system that passes the CFToken and CFid via WDDX from one server to a dataserver via CFHTTP. By passing the identifiers we ensure that the user's session is labeled the same on both servers even though each contains different data sets.