Here is a question I received via e-mail over the weekend, and my response. I thought it was worth sharing.
What does the “Use J2EE session variables” ColdFusion Administrator option do, and should I use it? And if I should use it, why is that option not checked by default?
There are two ways that session data can be managed in ColdFusion MX, via ColdFusion, or via the underlying J2EE server. Regardless of which mechanism is used, session variables are created and accessed using the SESSION prefix. The difference between the two options manifests itself in two ways. 1) ColdFusion sessions are identified using a CFID and a CFTOKEN, whereas J2EE managed sessions are identified using a jsessionid. 2) The real difference is that ColdFusion managed sessions are only accessible by ColdFusion, whereas J2EE managed sessions may be shared between ColdFusion and other Java code (JSPs, Servlets, etc.). There is no reason whatsoever not to use J2EE session variables, and there is significant benefit in using them. The only reason that the checkbox is not enabled by default is because of backwards compatibility. Ideally no CFML code should be referring to CFID and CFTOKEN explicitly, but if any code did then that code would break if J2EE session variables are used (as CFID and CFTOKEN are not generated when using J2EE session variables). If your code (or any code on the server, it is a server-wide setting) does not ever refer to CFID and CFTOKEN then you can safely turn on that option. On any new development on new boxes I’d definitely check the “Use J2EE session variables” checkbox.
Should I Use J2EE Session Variables?
6 responses to “Should I Use J2EE Session Variables?”
-
Does this mean that appending URLToken in URL’s or as a hidden form field is not necessary? Or even cflocation addtoken="yes" is not necessary?
-
Another good reason to use J2EE Session variables: CFID/CFTOKEN are stored as persistent cookies on users’ hard drives; jsessionid is a transient (in-memory) cookie that exists only for the duration of the users’ session. Many browsers that block cookies being set on disk will allow cookies being set in memory so jsessionid is less intrusive.
-
Peter, the id still needs to be sent back and forth, there is no real way around that one.
-
Hello Ben,
Recently, we migrated to CFMX. We are referring to any CFID & CFTOKEN values in any of our applications. Right now, we have the option ‘Use J2EE Session variables’ checked. After migrating to MX, I see that after logging into any application, the action page has the CFID, CFTOKEN & JSESSIONID appended to the URL. I am not sure what is the reason for that. Is there any way that I can get rid of appending those values to the URL as it is a security threat.
Thanks,
Mahesh. -
I have a problem with locking when using J2ee session variables, Jrun4 and cfmx6.1. When I use a scoped lock rather than a named lock cold fusion throws an error.. Any ideas?
-
Hello all…I see this topic is very old, but still a problem for me…I dont want sessions persisting after a browser closes a window…or i at least dont want a user to be able to access a previous session via URL parameters of cfid, cftoke, and jsessionid…i have J2EE sessions enabled…what am i missing here?
Maybe someone could tell me how to stop the appending of the cfid, cftoken, and jsessionid…
Thanks!
Justin
Leave a Reply