Cookies

When this option is selected from the session manager pane, the plug-in will use the JSESSIONID to manage requests. This name is required by the Servlet 2.3 specification. The session management tracking mechanism can be performed at the appserver, Web container, or the Web module level. To learn more about this, refer to Chapter 14, "Configuring session management" of the redbook IBM WebSphere Version 5.0 System Management and Configuration, SG24-6195.

To use the cookie JSESSIONID, users must have their browsers set up to allow cookies.

None of the workload management issues discussed in SSL ID applies to cookies. The browser can be connected to any Web server and there will be no effect on the session. Cookie session identifiers will survive a Web server crash and, provided persistent sessions are enabled, will also survive unavailability of the appserver.

The session lifetime is governed by the cookie lifespan. By default, WebSphere defines its cookies to last until the browser is closed. It is also possible to define the maximum age of the cookie in the cookies configuration.

 

When to use cookies

Cookies are the most common method of tracking the session. They work well in a workload-managed environment, with ease-of-use advantages over SSL IDs.

They do not require additional application coding and can be used from static HTML links, unlike URL rewriting.

The fact that any user can turn off cookie support in his/her browser could be more important to your application. If this is the case, then one of the other options must be considered.

If security is important, then it is possible to use cookies in an SSL environment and not have the overhead of setting up SSL session ID management.

  Prev | Home | Next

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.