Welcome!

You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

New Possibilities for Session/Client Variable Handling in CFMX

New Possibilities for Session/Client Variable Handling in CFMX

Tucked away among the press and praise about ColdFusion MX are some new options that could benefit every CF developer.

If you've seen them mentioned, they may not have seemed important at first glance, but I hope you'll give them consideration.

In this article I'll uncover some possibilities for session and client variable handling in CFMX - actually three new features you can choose to enable. I'll not only explain what they are, but why they're important and some other things to be aware of.

Are you thinking, "I already know about J2EE session variables"? That's not what this is all about. It is indeed one of the three new features, but the other two aren't dependent on that one and are of value to any CF developer. One of them doesn't even require any change to your code to obtain substantial benefits. The features are detailed under the following headings:

  • The New URLSessionFormat() Function
  • Using a UUID for CFTOKEN
  • Using J2EE Session Variables
Before proceeding, I should point out that, despite the name of the first new feature, both it and the second feature are related not just to session variable handling, but to supporting client variables as well. A few challenges that people have faced in working with both kinds of variables may indeed now be solved. You may even learn a new thing or two, as there are many misunderstandings about how these processes work. Let's start by setting the stage for the first feature.

Handling Session and Client Variables Without Cookies
The first new feature is a real hidden gem that hasn't been played up much at all. To understand its value, some background may be necessary. If you've needed to support session (or client) variables, you know that these features rely primarily on the browser supporting cookies to keep track of the user's identity (using what CF calls the CFID and CFTOKEN values it generates for each visitor).

Problems arise for browsers that don't support (or are by mandate not allowed to accept) cookies when they visit your site. In that case you must manually append the CFID and CFTOKEN to the URL used in any HTML you send to the browser that passes the user back to your server, such as <A HREF> and <FORM ACTION>. (The <CFLOCATION> tag also has an option called ADDTOKEN="yes" that accomplishes the same thing.)

If you haven't been paying attention to this issue, you may be suffering when users who don't support cookies visit your site. They never keep session variables from page to page, for instance. That can wreak havoc on a login process. And they also can't keep client variables from visit to visit.

The converse is that you shouldn't always append these values to a URL because that leaves your site open to several potential problems. If someone passed a bookmark of a URL with a given CFID/CFTOKEN pair shown, the user receiving that bookmarked URL would also now use the first user's CFID/CFTOKEN pair. Have you ever heard of two people seeming to share a session? This is one way it happens.

Another challenge is that someone can just guess at CFID/CFTOKEN values when displayed this way on a URL (more on another way to solve that problem in a moment).

So the optimal way to handle this (pre-CFMX) is to somehow test whether cookies are supported for the user running the template and then, only if they're not, append the CFID/CFTOKEN value. The code to do that isn't difficult, but getting it right and then placing that CFID logic around every instance of <A HREF>, <FORM ACTION>, or <CFLOCATION> (deciding whether to use ADDTOKEN="yes") could be challenging.

New URLSessionFormat() Function
Enter the new URLSessionFormat function. With this simple function you can now let CFMX worry about whether to append the CFID/CFTOKEN pair (and/or the JSessionID if using J2EE sessions, as discussed in a moment). Here's a simple example:

<cfoutput>
<a href="#URLSessionFormat
("MyPage.cfm?name=bob")#">
some link</a></cfoutput>
If CFMX detects that the browser executing this template isn't passing the needed cookie (CFID/CFTOKEN for CF session and client variables, JSessionID for J2EE session variables), then it will turn that output HTML into the following:

<a href="MyPage.cfm?name=
bob& cfid=xxxx&cftoken=xxxxxxxx">some link</a>
On the other hand, if CFMX detects that the needed cookies are being passed in by the browser, it leaves the identifiers off. Very cool! Note that it's smart enough to realize if the URL already has something in the query string (as it does above), in which case it uses an ampersand (&) to append the identifiers. Ta-da! (In that example I'm not yet showing what it looks like if J2EE sessions are being used.)

There is one gotcha: if you also need to use a URLEncodedFormat function for some part of the query string that has embedded spaces or special characters, it could become pretty cumbersome to use both functions in a single line of code, with embedded functions and strings within those functions. The following looks ugly, but it will work:

<cfoutput>
<a href="#URLSessionFormat
("MyPage.cfm?name=#URLEncoded
Format("billy bob")#")#">some link</a>
</cfoutput>
One other observation: I've noticed that when using J2EE sessions, it's possible for the resulting URL to appear in the format My Page.cfm;JSESSIONID=803094969 1025145133137?name=bob. Note that in this case the JSessionID is appended to the filename separated by a semicolon, rather than to the query string. Still, when that's happened, the URL has functioned as expected.

It may be worth pointing out that, technically, this function's name isn't completely accurate. It's needed not just for session variable handling but client variable handling as well. In other words, if you use client variables but not session variables, this is still the way to guarantee that the CFID/CFTOKEN pair needed for client variable support as well is sent to browsers that don't allow cookies. (Indeed, if client variables are in use in that previous example showing the JSessionID, then the CFID and CFTOKEN would be appended to the query string as they were above.)

You also shouldn't dismiss browsers that don't support cookies as being antiques not worthy of your concern: many organizations force users to disable cookie support in their browsers. This solution helps you support them as well.

Using a UUID for CFTOKEN
I mentioned previously that one of the challenges of CFID and CFTOKEN pairs is that if the value is displayed on the URL, it's just very easy to try to guess. The CFID/CFTOKEN values are just a few simple numbers. By trying different numbers, a user may be able to impersonate or "spoof" another user's session (or client) variables. (And this really isn't a concern just if you pass them on the URL. Anyone familiar with the process can simply type a CFID/ CFTOKEN pair on any URL running a CF template and, though the odds may be slim, possibly guess an active pair.)

So another new feature of CFMX, which has nothing to do with J2EE session variables, is that you can ask the server to generate more elaborate UUIDs (Universal Unique Identifiers) for the CFTOKEN. This is enabled in the Administrator, on the "server settings" page, by checking the option "Use UUID for cftoken". (The fact that this is not on the "memory variables" page reinforces the point that the CFTOKEN is used for both client and session variables.) You'll need to restart the CFMX server for this change to take effect. You needn't change any code to benefit from this new feature.

After enabling them, you may see that CFTOKEN values look more like this, as an example: 15ce46ab4e29a f0a-AF695847-F92F-344A-13325 2991FB6C3B5. (You can see it yourself with <cfoutput>#cftoken#</cf output>.) Definitely a lot harder to randomly guess an active value! It's a feature that probably should be enabled by all sites, just for the added protection. The only risk is if you have any code that for some reason relies on the CFTOKEN being the simpler 8-digit number (or are storing the CFTOKEN in a database column that needs to be widened).

A side note: The ability to use a UUID for CFTOKEN isn't really new in CFMX. It's just easier to enable. In CF4.5 and 5 it requires a manual registry change. See the Macromedia TechNote at www.macromedia.com/v1/Handlers/index.cfm?ID=22427&Method=Fullfor more information.

Using J2EE Session Variables
I mentioned in the first section that CF now supports "J2EE sessions." What are they? And why would you care? Well, as a coder, it's possible that they'd only add benefit and, again, there's little reason not to use them. It's another feature set in the CFMX Administrator, in the "memory variables" page, checking the "Use J2EE session variables" option and restarting the server.

J2EE sessions work by sending to the client a cookie not with CFID and CFTOKEN but JSessionID. (Again, if CFAPPLICATION has CLIENTMANAGEMENT="yes", then the CFID/CFTOKEN pair is still sent, to support client variables only.)

There's more to the difference between the CFID/CFTOKEN pair and JSessionID than the name. First, the JSessionID value is a more elaborate combination of characters (including a UUID). As mentioned previously, the default CFID/CFTOKEN pair values are simply a few numbers each. That may make them possible to guess. Then again, you've just learned that you can change the CFTOKEN to use a UUID, so that benefit may seem diminished.

But there are still more differences, and they can be very important to some. First, and coolest of all, is that J2EE sessions work the way most developers have long wished CF session variables would: when the user closes his or her browser, the session is terminated as well. Hallelujah!

How does the mechanism work that allows the session to terminate when the browser is closed? Maybe you've already guessed: the JSession-ID that's used for J2EE sessions is set as a nonpersistent (or "per-session" or "temporary") cookie. That means simply that the cookie value isn't stored persistently in the browser user's hard drive. It's held only in the browser's memory. When the browser (all its instances) is closed, the JSessionID is lost. On a subsequent visit in a new browser window, the user is given a new JSessionID.

Technically, the session will live on in CFMX's memory until it times out. But with the user no longer holding the JSessionID for it, it's effectively "terminated" as far as he or she is concerned.

This also points out another benefit of using J2EE sessions for those organizations that aren't allowed to use persistent cookies (such as the CFID and CFTOKEN cookie values set by CFMX and previous versions). These organizations can use J2EE sessions much more easily than they could CF-based sessions. Of course, there are ways in all releases of CF that they could force the CFID and CFTOKEN to be nonpersistent, as outlined in the Macromedia Tech-Note at www.macromedia.com/v1/Handlers/index.cfm?ID=21079&Method=Full. With J2EE sessions, they needn't bother with that.

One final benefit of using J2EE sessions, which may or may not impress most CF developers, is that using them allows sharing of session variables with JSP and servlet programs also run under CFMX. That could be valuable, if you start exploring that capability. For more about sharing session and application variables between CF and JSP/servlet pages, see Chapter 32 of the CFMX manual, Developing ColdFusion MX Applications with CFML, available online at http://livedocs.macromedia.com.

Summary
Again, there's more to what's new in session variable support in CFMX than just J2EE sessions. Those first two items are valuable to all CFMX developers and apply to client variables as well (and the second one can apply even to users of CF4.5 and 5). The features add new dimensions in security, flexibility, and capability. Check them out!

More Stories By Charlie Arehart

A veteran ColdFusion developer since 1997, Charlie Arehart is a long-time contributor to the community and a recognized Adobe Community Expert. He's a certified Advanced CF Developer and Instructor for CF 4/5/6/7 and served as tech editor of CFDJ until 2003. Now an independent contractor (carehart.org) living in Alpharetta, GA, Charlie provides high-level troubleshooting/tuning assistance and training/mentoring for CF teams. He helps run the Online ColdFusion Meetup (coldfusionmeetup.com, an online CF user group), is a contributor to the CF8 WACK books by Ben Forta, and is frequently invited to speak at developer conferences and user groups worldwide.

Comments (3) View Comments

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.


Most Recent Comments
SS 10/20/04 11:28:11 AM EDT

I guess the only alternative left with us would be to force users to enable cookies in IE as MS is not going to address this issue when it has many on its plate. As far as MM is concerned, lets wait for the next release, something should come up.

charles arehart 09/08/02 04:36:00 AM EDT

I'd like to add a couple more observations about using J2EE sessions.

First, when you enable J2EE sessions, CFMX no longer creates the variables session.cfid and session.cftoken. If you're using those to attempt to persist sessions when (or in case) cookies aren't supported, those values are no longer available once you enable J2EE sessions.

You might think to try to use the available session.URLToken variable instead (or cookie.jsessionid, which does exist on the server while the page is being executed). Unfortunately, niether of these will work.

CFMX can only receive a jsessionid on a URL if it's appended after the filename and extension as ;jsessionid=nn, a format that was discussed in the article. This is the reason for the URLSessionFormat function, which was also discussed in the article.

But the caveats above explain why that's problematic in an IIS environment.

And it turns out that the problem above is even larger than I first learned.

If you enable J2EE sessions and then use CFLOCATION, and a browser executes the page but doesn't support cookies or doesn't present any to the page, CFMX will append the ;jsessionid after the filename and extension as discussed in the article. That's great for the built-in CFMX web server.

Unfortunately, if the redirection is to an IIS server (whether yours or another), the request will fail. Even using the ADDToken="no" won't stop it doing this.

Either MM needs to address this, or Microsoft needs to change IIS to allow this sort of URL.

charles arehart 09/03/02 05:44:00 PM EDT

I had mentioned in the article that the new URLSessionFormat would, when when using J2EE sessions, cause the resulting URL it generates to appear in the format templatename.cfm;JSESSIONID=803094969 1025145133137. Note that the JSessionID is appended to the filename separated by a semicolon, rather than to the query string.

I added that "Still, when that's happened, the URL has functioned as expected."

Well, I was doing testing at the time on the built-in CFMX web server. I've since discovered that if you're doing this on an IIS web server, the use of the ;jsessionid after the filename causes a 404 file not found. This is disappointing.

If you use J2EE session variables and are working under an IIS web server, don't use the URLSessionFormat, at least until this problem is resolved by MM. (The problem really ought to be solved by MS.)

IoT & Smart Cities Stories
Early Bird Registration Discount Expires on August 31, 2018 Conference Registration Link ▸ HERE. Pick from all 200 sessions in all 10 tracks, plus 22 Keynotes & General Sessions! Lunch is served two days. EXPIRES AUGUST 31, 2018. Ticket prices: ($1,295-Aug 31) ($1,495-Oct 31) ($1,995-Nov 12) ($2,500-Walk-in)
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next...
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
All in Mobile is a place where we continually maximize their impact by fostering understanding, empathy, insights, creativity and joy. They believe that a truly useful and desirable mobile app doesn't need the brightest idea or the most advanced technology. A great product begins with understanding people. It's easy to think that customers will love your app, but can you justify it? They make sure your final app is something that users truly want and need. The only way to do this is by ...
DXWorldEXPO LLC announced today that Big Data Federation to Exhibit at the 22nd International CloudEXPO, colocated with DevOpsSUMMIT and DXWorldEXPO, November 12-13, 2018 in New York City. Big Data Federation, Inc. develops and applies artificial intelligence to predict financial and economic events that matter. The company uncovers patterns and precise drivers of performance and outcomes with the aid of machine-learning algorithms, big data, and fundamental analysis. Their products are deployed...