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.
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.
ColdFusion has two types of session management:
- Traditional Session Management
- J2EE Session Management (ColdFusion MX introduces) ColdFusion State/Session Management
Using the Code
1. Traditional Session Management
Traditional coldfusion session management uses the
CFTOKEN values to track user's browser session. Here the
session.sessionid comprises application name, CFID and CFTOKEN value.
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
CFTOKEN together form the browser ID.
ColdFusion uses two numbers (
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
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,
CFTOKEN values are persisted from request to request.
- You can store
CFTOKEN in a cookie on the user's browser. This cookie is sent back to ColdFusion with every request.
You can pass
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
CFTOKEN is set an attribute in your
CFAPPLICATION tag, as follows:
<cfapplication ... setclientcookies="Yes">
ColdFusion handles the setting and retrieving of
CFTOKEN. The problem with this automatic handling of
CFTOKEN is that it requires that the user have cookies enabled. If the user has disabled cookies, you can't set client variables so
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
CFTOKEN with each request.
If you want to set client variables even if users have cookies disabled, you must pass
CFTOKEN as URL parameters in every URL in your site so that ColdFusion can see who you are, as the following code shows:
You also have a new syntax in ColdFusion MX that automatically chooses whether the page needs the URLToken appended to the end, as follows:
If the user has cookies enabled,
URLSessionFormat () returns the URL unmodified. If cookies are disabled,
URLSessionFormat() automatically appends the
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
- 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.
- 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:
- Step-4: Add the following entry ? Note the case ? For this key on the line below the "
- 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
CFTOKEN. ColdFusion MX still creates the
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
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 variables now use
JSESSIONID to identify the user's session, but Client variables still use
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.
URLSessionFormat() creates a URL as follows:
If J2EE sessions are enabled (and Client variables are disabled), however,
URLSessionFormat() creates a URL similar to the following:
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 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:
Why do we use
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.
CFToken as non-persistent cookies.
UUID CFToken for stronger ColdFusion session identifiers.
- Try to avoid passing session identifiers (
JESSIONID) on the URL.
- For J2EE sessions, ensure the session-timeout parameter is greater-than-or equal-to ColdFusion's Maximum Session Timeout.
- Only enable J2EE Session Variables if all applications on the server will be using it. Do not enable if applications require Client Management.
- If cookies are not available, use the
URLSessionFormat function for links.
- Lock read/write access to
Session variables which may cause race conditions.
- Do not overwrite the default Session variables.
- Loop over
StructDelete(Session.variable) instead of using
StructClear(Session) to remove variables from the Session scope.
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.
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
- 15th September, 2007: Initial post
- Chandrakanta Kar (Software Engineer, Mindfire Solutions)