CODEWITHSUNDEEP
sessionjakarta-eecoldfusion
nosilleg
nosilleg

Reputation: 2163

ColdFusion sessions vs J2EE sessions

Are there any benefits to ColdFusion sessions vs J2EE sessions?

The ColdFusion session documentation mentions the benefits of J2EE sessions, but not any advantages of ColdFusion sessions. J2EE sessions have been available since ColdFusion MX (released in 2002), but there are still a lot of people using standard ColdFusion sessions. Are there any disadvantages of J2EE sessions that aren't present with ColdFusion sessions?

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

  • J2EE session management uses a session-specific session identifier, jsessionid, which is created afresh at the start of each session.
  • You can share session variables between ColdFusion pages and JSP pages or Java servlets that you call from the ColdFusion pages.
  • The Session scope is serializable (convertible into a sequence of bytes that can later be fully restored into the original object). With ColdFusion session management, the Session scope is not serializable. Only serializable scopes can be shared across servers.

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

  • You want to maximize session security, particularly if you also use client variables
  • You want to share session variables between ColdFusion pages and JSP pages or servlets in a single application.
  • You want to be able to manually terminate a session while maintaining the client identification cookie for use by the Client scope.
  • You want to support clustered sessions; for example, to support session failover among servers.

Upvotes: 6

Views: 3449

Answers (4)

nosilleg
nosilleg

Reputation: 2163

One of the main disadvantages of J2EE session variables in ColdFusion is that changes such as making them "secure" cookies takes place instance wide.

This means that every site that is running on that instance must run under https, including ColdFusion administrator itself. For servers that host multiple sites that require sessions, this will generally be problematic. Additionally, if you're running the ColdFusion Administrator from the built in web server, there's a bit of a process to get that working under ssl.

If you need the documented advantages of J2EE cookies, and need the cookie to be secure then all sites that requires sessions must be on https.

If you don't need any of the documented advantages of J2EE cookies, and you're running CF9 or later, then you're better off going with ColdFusion cookies.

Note that Railo still has the same issue but with more flexibility since the cfapplication tag has a sessiontype attribute where you can choose between j2ee or cf session cookies on a per site basis.

Upvotes: 1

Kung Fu Ninja
Kung Fu Ninja

Reputation: 3752

I had one tiny problem where I completely lost session variables between requests. I was using a cfhttp post with J2EE sessions. Imagine this scenario: 1. call.cfm in wwwRoot/test folder makes a call to an index page also in the same folder. 2. index.cfm sends the 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 session variables created.

All the send requests are done via cflocation with addtoken="yes".

Turn off the J2EE session variables, and viola! It works just like the way it should.

cflocation and session variables

Upvotes: 0

Jason Dean
Jason Dean

Reputation: 9615

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

The one disadvantage to Java EE tokens is that the cookies cannot be easily modified programmatically. CF Tokens can. You can modify CF Tokens to be session only. You can also modify them to be SSL-only and httpOnly.

You can make Java EE tokens SSL-only and httpOnly as well, but it involves JVM arguments.

In CF9, Adobe 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 (assuming you're on CF9 or higher). But Java EE Tokens are the closest to working securely out-of-the-box. But if you want to go beyond just setting the cookies to "session-only" and have them be SSL-only and httpOnly, you'll need to dig into the JVM settings. You cannot do that in your App.cfc.

Upvotes: 3

barnyr
barnyr

Reputation: 5678

CF native sessions don't use Session cookies, so can last across browser/machine restarts, whereas all Java EE servers by default use session cookies,so your session can only last as long as your browser is open.

I can't find where this behaviour is specified in the Servlet JSR, but in Servlet Spec 3.0 (i.e. not JRun) , you can set an expiry date for your Java EE session cookie in order to mimic the CF native session behaviour.

As nosilleg mentions, this is could be a bonus, but also could be seen as a security problem, depending on the security requirements of the app your're working on.

Upvotes: 1

Related Questions