Memory variables allow your application to persist data globally (application variables) or across user sessions (session variables). Memory variables are useful for maintaining logins, incrementing counters, and other stateful information. This section of the ColdFusion Administrator controls how the server manages these variables.
J2EE Session Variables
The server supports two kinds of session variables, ColdFusion and J2EE. Introduced in ColdFusion MX, J2EE session variables provide significant advantages over traditional ColdFusion session variables.
- More secure: J2EE session variables provide a more complex identifier, which strengthens session security.
- Session sharing: Session data can be easily shared between ColdFusion and Java Server Pages (JSP) and servlets
- Session management: User sessions can be terminated without losing client management or client identification tokens (
CFIDEandCFTOKEN).
We strongly recommend enabling J2EE session variables for your application. Note that there are several important distinctions between these session management options, and your application should be fully tested before this change is released to production. J2EE session management creates a new variable (jsessionid) which is created at the start of a browser session. When the browser is closed, jsessionid is destroyed, thereby ending the session. If your application relies on user sessions persisting across browser sessions, you may need to consider another storage option.
Tip: If you intend to implement ColdFusion Clustering on Enterprise ColdFusion, you must use J2EE sessions. The default is unchecked.
Tip: Be sure to review our ColdFusion security recommendations to help secure your server.
Session Storage Settings
The Enterprise version of ColdFusion provides the option to store session data externally. This is especially useful if you intend to implement ColdFusion Clustering. The In Memory capability is not as robust as Redis at replicating session data across clustered instances. As clustering is an Enterprise only feature, the Redis option for session storage is worthy of consideration.
Tip: If you intend to use external session storage (such as Redis) then you must disable J2EE session variables (see above).
Note: You must restart the ColdFusion application server to change the session storage.
Maximum Timeout
Here you can specify an upper limit for application and session variable timeouts in ColdFusion. This establishes a not-to-exceed maximum for your individual applications. Any sessiontimeout or applicationtimeout values in <cfapplication>, or the Default Timeouts shown below, may not exceed these limits.
Default Timeout
Here you can set application and session timeouts that apply to all application bound to this instance of ColdFusion. We recommend setting reasonable limits here but also overriding these settings within your individual applications (within the <cfapplication> tag). Ideally, these limits should be as short in duration as possible without negatively impacting user experience. Specific, targeted functional testing of your application is the best means of discovering optimal settings for your application.
Tip: If users are being logged out of your site too quickly, you may want to try a longer session length here.
These timeouts may not exceed the maximum limits established in the Maximum Timeout length.
Session Cookie Settings
Settings in this section can have a security impact on your application. We recommend enabling HTTPOnly, which is the default and prevents JavaScript from accessing the cookies. In addition, we recommend setting Disable updating ColdFusion internal cookies using ColdFusion tags/functions be enabled (checked). This prevents ColdFusion code from being able to manipulate these critical cookies, lending a higher level of security to the application. This setting is unchecked by default. Testing these settings is important before deployment to your production environment.