Introduction

This article is used to provide the idea regarding how the ColdFusion Application Server maintains state and how many different types of Session management are available for ColdFusion.

It can solve the problems of people working with ColdFusion integration with Java Servlet, and other specific integration.

Background

State Management: State management consists of two parts:

Identifying a session based on the browser ID

Expiring the session after too much time (i.e., the time passes greater than "sessiontimeout" attribute value of cfapplication tag inside the application.cfm or application.cfc file) passes between requests from a given user.

1. Traditional Session Management

By default, all ColdFusion versions write CFID and CFTOKEN as persistent cookie values in the client browser with the cfapplication tag. Persistent cookies are cookies that exist even after a client browser is closed or we can say persistent cookies remain available for future browsers.

Identifying a session by using CFID and CFTOKEN values

If you have used CFLOCATION tag without setting "addToken" attribute value to "no", then you may have noticed that ColdFusion adds two URL parameters to the end of the URL. The combination of CFID and CFTOKEN together form the browser ID.

ColdFusion uses two numbers (CFID and CFTOKEN) instead of a single ID value. It's a precaution that makes guessing the complete browser ID harder for someone. CFID is a monotonically increasing number, so the first session on the server gets CFID 1, the next session gets CFID 2, and so on. You can probably imagine that if you were CFID number 5000, guessing that the session before you was CFID 4999 wouldn't be too hard, and assuming session 4999 and possibly gaining access to private data would be easy for you. That's why CFTOKEN is used with CFID. CFTOKEN is an eight-digit random number that ColdFusion generates along with CFID. You can't predict the CFTOKEN as you can the CFID, so it adds an extra measure of security.

Ways of Persisting CFID and CFTOKEN Between Requests

In the following two ways, CFID and CFTOKEN values are persisted from request to request.

You can store CFID and CFTOKEN in a cookie on the user's browser. This cookie is sent back to ColdFusion with every request.

You can pass CFID and CFTOKEN in the URL of every request. This overrides any value that may also be stored in a cookie.

All you need to do to set a cookie for CFID and CFTOKEN is set an attribute in your CFAPPLICATION tag, as follows:

<cfapplication...setclientcookies="Yes">

ColdFusion handles the setting and retrieving of CFID and CFTOKEN. The problem with this automatic handling of CFID and CFTOKEN is that it requires that the user have cookies enabled. If the user has disabled cookies, you can't set client variables so CFID and CFTOKEN can't use for more than one request—because ColdFusion can't see the cookie, and Server assumes that the user has not visited the site before and assigns a new CFID and CFTOKEN with each request.

If you want to set client variables even if users have cookies disabled, you must pass CFID and CFTOKEN as URL parameters in every URL in your site so that ColdFusion can see who you are, as the following code shows:

<ahref="pagename.cfm?CFID=#Client.CFID#&CFTOKEN=#Client.CFID#">

Or:

<ahref="pagename.cfm?#Client.URLToken#">

You also have a new syntax in ColdFusion MX that automatically chooses whether the page needs the URLToken appended to the end, as follows:

<ahref="#URLSessionFormat('pagename.cfm')#">

If the user has cookies enabled, URLSessionFormat () returns the URL unmodified. If cookies are disabled, URLSessionFormat() automatically appends the CFID and CFTOKEN to the URL.

Using a UUID for CFTOKEN

By default, Macromedia Coldfusion Server versions 4.5 and 5 assign a random eight-digit integer as a CFTOKEN value and Macromedia Coldfusion Server MX versions uses a crytographic-strength generator to create the random eight-digit CFTOKEN value. ColdFusion Server no longer validates any part of this token, allowing users to reassign this to any value they choose. It is possible for the same CFTOKEN value to be given to more than one user.

To strengthen the CFTOKEN value by making it a Universally unique number or impossible-to-guess, ColdFusion provides UUID (Universally Unique Identifier) value as shown below:

To get the Universally Unique CFTOKEN, we have to do some setting according to their versions.

For ColdFusion 4.5 and 5

On Windows Operating System

Step-1: Select Start > Run

Step-2: Type "regedit" and click OK.

Step-3: Navigate to the following registry key:HKEY_LOCAL_MACHINE\Software\Allaire\ColdFusion\CurrentVersion\Clients\UuidToken, if the key does not exist, right click on the clients key and choose New > String Value. Name the key UuidToken.

Step-4: Right click the UuidToken registry key. Select Modify.

Step-5: Enter a non-zero string value.

Step-6: Restart the ColdFusion Application Server.

On Linux\Unix

Step-1: Stop the ColdFusion processes (./cf_root/bin/stop -force).

Step-2: Open the cf_root/registry file in an editor (Vi, emacs, etc.).

Step-3: Navigate to the following registry key:hkey_local_machine\software\allaire\coldfusion\currentversion\clients:7

Step-4: Add the following entry ? Note the case ? For this key on the line below the "TimeOut" entry:

UuidToken: 1; REG_SZ

Step-5: Save the file and close the editor.

Step-6: Restart the ColdFusion processes (./cf_root/bin/start).

For ColdFusion MX 6.1 and MX 7.0

Step-1: Log in to the ColdFusion Administrator.

Step-2: Click Setting in the left navigation.

Step-3: Check the box provided for "Use UUID for CFTOKEN."

Step-4: Click the "Submit Changes" button.

Step-5: Log out from the ColdFusion Administrator.

Step-6: Restart the ColdFusion MX Application service.

2. J2EE Session Management ( ColdFusion MX introduces)

ColdFusion MX (CFMX) introduces J2EE Servlet session management in addition to the traditional ColdFusion session management. J2EE session management enables the sharing of session information between ColdFusion pages and JSP pages or Servlets within a single application. With J2EE session management, ColdFusion uses a new variable, the JSESSIONID, to track a user's browser session instead of CFID/CFTOKEN. ColdFusion MX still creates the CFID and CFTOKEN values, however, but these values are no longer used to uniquely identify browser sessions. J2EE session management does not require an Application name, so the SESSION.SESSIONID value becomes the JSESSIONID. Because the JSESSIONID is always written as a per-session value, it is destroyed when the browser is closed and a new one is created with each new browser session. JSESSIONID value is highly random.

JSESSIONID works in much the same way that CFID and CFTOKEN do. If a request is made that has no JSESSIONID attached, ColdFusion generates a new JSESSIONID and stores it in a non-persistent cookie on the user's browser. If the browser doesn't support cookies, you can pass JSESSIONID in the URL (All must be in uppercase), and ColdFusion uses the JSESSIONID from the URL to identify a user's session.

By enabling J2EE Session Management now splits the state-management mechanism into two parts:

Session

Client

Session variables now use JSESSIONID to identify the user's session, but Client variables still use CFID and CFTOKEN, because Client variables are not interoperable with JSP, as Session variables are. With J2EE session management enabled, CFML can share its Request, Session, and Application scopes with JSP and J2EE Servlet applications. You can't share Client variables with these non-ColdFusion applications, however, because J2EE doesn't use them.

Steps Required to Enable J2EE Session Management

To enable J2EE session management, the steps given below should be followed:

Log in to ColdFusion Administrator.

Go into the Memory Variables section.

Select the Use J2EE Session Variables checkbox.

Click Submit.

Restart both ColdFusion server and your Web server after enabling this option.

Problem Using URLSessionFormat() while J2EE sessions are enabled

You can use URLSessionFormat() to add JSESSIONID to the URL if necessary (if the client side cookies are not enabled). You do face a problem, however, in using URLSessionFormat() while J2EE sessions are enabled.

Normally, URLSessionFormat() creates a URL as follows:

http://127.0.0.1/pagename.cfm?CFID=2136&CFTOKEN=25334417

If J2EE sessions are enabled (and Client variables are disabled), however, URLSessionFormat() creates a URL similar to the following:

http://127.0.0.1/page.cfm;JSESSIONID=8030379221028482598796

instead of a question mark as in the first one, a semicolon introduces JSESSIONID. The semicolon is part of the J2EE Servlet standard, but Microsoft's Internet Information Server and Apache Web Server may not recognize the semicolon as valid. As such, attempting to use the URL from URLSessionFormat() if J2EE sessions are enabled may lead to a 404 File Not Found error if running against these incompatible Web servers.

Adding Client variables to the mix complicates the problem even more, as the following shows:

The semicolon is still there before JSESSIONID but the normal question mark that introduces the query string is appended after the JSESSIONID. Again, JSESSIONID is included twice, but the second version is lowercase, in violation of the J2EE standard.

Solution using URLSessionFormat() while J2EE sessions are enabled

The best solution is to use URLSessionFormat() if your Web server supports a semicolon as the character that delimits the URL from its parameters:

If not, append "Session.URLToken" to the page URL, as follows:

<ahref="page.cfm?#UCase(Session.URLToken)#">...</a>

Why do we use Ucase()? URLToken is included as a lowercase parameter; J2EE, however, requires that JSESSIONID be included as uppercase. If you don't include the call to UCase(), state is not maintained between requests.

Points of Interest

MAKE IT A PRACTICE WHEN WORKING WITH SESSION MANAGEMENT:

For better purpose, you can set session timeout values to 20 minutes or less.

Create CFID and CFToken as non-persistent cookies.

Enable UUID CFToken for stronger ColdFusion session identifiers.

Try to avoid passing session identifiers (CFID/CFToken or JESSIONID) on the URL.

Loop over StructDelete(Session.variable) instead of using StructClear(Session) to remove variables from the Session scope.

If clientManagement = "Yes" and clientStorage="Cookie", do not store sensitive information in the client's cookie. Any information that could aid in identity theft if revealed to a third-party should not be included in a cookie. For example, credit card number, security code for back account, SSN, etc.

Conclusions

State/Session Management is an important task for any web based applications. So you should be careful to maintain that in your application. Here you found each one having its own way of representation, but for more security purposes, you can chose any one between J2EE or UUID type.

Comments and Discussions

Usually if we need to do some setting changes for ColdFusion application server then we log into ColdFusion Administrator using ColdFusion Admin GUI and change the settings. We can also do all the ColdFusion Administrator setting changes programmatically through ColdFusion Administrator API calls. ColdFusion provides us with around 12 components for different sections of the Administrator. We can call the different methods of different components to change the settings.

The basic component file containing the methods related to login and logout functionality for ColdFusion Administrator is "administrator.cfc". With the login method of this component, we can log into the Administrator by providing the ColdFusion Administrator login password. Once we log in, we can use the other methods of the components to perform other functionalities like creating datasource, creating mapping, modifying the debugging output settings etc.