ColdFusion Sessions and J2EE Sessions

Question

Are there any benefits for ColdFusion sessions and J2EE sessions?

ColdFusion session documentation mentions the benefits of J2EE sessions, but not the benefits of ColdFusion. J2EE sessions are available with ColdFusion MX (released in 2002), but many people still use standard ColdFusion sessions. Are there any flaws in J2EE sessions that are missing from ColdFusion sessions?

J2EE session management provides the following advantages over ColdFusion session management:

• Session Management J2EE uses the session identifier for the session, jsessionid , which is recreated at the beginning of each session.
• You can share session variables between ColdFusion pages and JSP pages or Java servlets that you invoke from ColdFusion pages.
• The session area is serializable (converted to a sequence of bytes, which can subsequently be completely restored to the original object). Using ColdFusion session management, a session area cannot be serialized. Only serializable areas can be shared between servers.

Therefore, consider using J2EE session management in any of the following cases:

• You want to maximize session security, especially if you also use client variables
• You want to split session variables between ColdFusion pages and JSP pages or servlets in the same application.
• You want to be able to manually end the session by storing the client identification cookie for use with the Client area.
• You want to support cluster sessions; for example, to support session switching between servers.

Answer 1

One of the major drawbacks of J2EE session variables in ColdFusion is that changes like their “safe” cookies are widespread.

This means that every site running on this instance must run under https, including the ColdFusion administrator. For servers hosting multiple sites that require sessions, this will usually be problematic. In addition, if you are using ColdFusion Administrator from the embedded web server, there is little process to get it working under ssl.

If you need the documented benefits of J2EE cookies and you want the cookie to be secure, all sites requiring sessions must be on https.

If you do not need any documented benefits of J2EE cookies and you are using CF9 or later, you are better off with ColdFusion cookies.

Please note that Railo still has the same problem, but with more flexibility, because the cfapplication tag has a sessiontype attribute, where you can choose between j2ee or cf session cookies for each site.

Answer 2

There are no serious drawbacks to using Java EE cookies, and there are some advantages to using them as mentioned in your question above.

The only drawback of Java EE tokens is that cookies cannot be easily modified programmatically. CF tokens can. You can modify CF tokens for a session only. You can also change them to be only SSL and httpOnly.

You can also use Java EE tokens for SSL and httpOnly only, but they include JVM arguments.

In CF9, Adobe has also improved the randomness of CF tokens to be more on par with Java EE tokens.

I really don't think it matters which one you use (if you're on CF9 or higher). But Java EE tokens are the closest to safe work out of the box. But if you want to go beyond cookie-only "session-only" settings, and let them be only for SSL and httpOnly, you will need to go into the JVM settings. You cannot do this in your App.cfc.

Answer 3

CF native sessions do not use session cookies, so they can continue through restarting the browser / machine, while all Java EE servers use session cookies by default, so your session can continue as long as your browser is open.

I cannot find where this behavior is specified in Servlet JSR, but in Servlet Spec 3.0 (i.e. not JRun), you can set the expiration date of your Java EE session cookie to mimic the behavior of a native CF session.

As Nosilleg mentions, this can be a bonus, but it can also be considered a security issue, depending on the security requirements of the application you are working on.

Answer 4

I had one tiny problem when I completely lost session variables between requests. I used the cfhttp message with J2EE sessions. Imagine this scenario: 1. call.cfm in the wwwRoot / test folder makes a call on the index page also in the same folder. 2. index.cfm sends a request to wwwRoot / test / controller / login.cfm. 3. login.cfm sets some session variables and sends the user to wwwRoot / test / index.cfm 4. index.cfm does not see the created session variables.

All send requests are made through cflocation using addtoken = "yes".

Disable J2EE and alt session variables! It works the way it should.

cflocation and session variables