Session tracking options
HTTP session support also involves session tracking. We can use cookies, URL rewriting, or SSL information for session tracking.
the following tracking methods are available:
- Session tracking with cookies
- Session tracking with URL rewriting
- Session tracking with SSL information
Session tracking with cookies
Tracking sessions with cookies is the default. No special programming is required to track sessions with cookies.
Session tracking with URL rewriting
An application that uses URL rewriting to track sessions must adhere to certain programming guidelines. The application developer needs to do the following:
- Program servlets to encode URLs
- Supply a servlet or JSP file as an entry point to the application
Use URL rewriting also requires that you enable URL rewriting in the session management facility.
In certain cases, clients cannot accept cookies. Therefore, we cannot use cookies as a session tracking mechanism. Applications can use URL rewriting as a substitute.
Program session servlets to encode URLs
Depending on whether the servlet is returning URLs to the browser or redirecting them, include either the encodeURL method or the encodeRedirectURL method in the servlet code. Examples demonstrating what to replace in the current servlet code follow.
Rewrite URLs to return to the browser
Suppose you currently have this statement:
- out.println("<a href=\"/store/catalog\">catalog<a>");
Change the servlet to call the encodeURL method before sending the URL to the output stream:
out.println("<a href=\""");
out.println(response.encodeURL ("/store/catalog"));
out.println("\">catalog</a>"");
Rewrite URLs to redirect
Suppose you currently have the following statement:
- response.sendRedirect ("http://myhost/store/catalog");
Change the servlet to call the encodeRedirectURL method before sending the URL to the output stream:
- response.sendRedirect (response.encodeRedirectURL ("http://myhost/store/catalog"));
The encodeURL method and encodeRedirectURL method are part of the HttpServletResponse object. These calls check to see if URL rewriting is configured before encoding the URL. If it is not configured, the calls return the original URL.
We can also configure session support to enable protocol switch rewriting. When this option is enabled, the product encodes the URL with the session ID for switching between HTTP and HTTPS protocols.
Avoid trouble: To encode a URL, enable the AlwaysEncodeURL custom property and set the value to true.
Session management properties, like the session management configuration, can be configured at the server, application, or web module level. The following steps are for setting the custom properties for session management at the server level.
- In the console click Servers > Server Types > WebSphere application servers > server_name > Session management.
- Under Additional Properties select Custom
Properties.
- On the Custom Properties page, click New.
- On the settings page, enter the property to configure in the Name field and the value to set it to in the Value field.
- Click Apply or OK.
- Click Save on the console task bar to save your configuration changes.
- Restart the server.
Supply a servlet or JSP file as an entry point
The entry point to an application, such as the initial screen presented, may not require the use of sessions. However, if the application in general requires session support (meaning some part of it, such as a servlet, requires session support), then after a session is created, all URLs are encoded to perpetuate the session ID for the servlet (or other application component) requiring the session support.
The following example shows how we can embed Java code within a JSP file:
<%
response.encodeURL ("/store/catalog");
%>
Session tracking with SSL information (Deprecated)
Deprecated feature: Session tracking using the SSL ID is deprecated in WebSphere Application Server version 7.0. We can configure session tracking to use cookies or URL rewriting.depfeat
No special programming is required to track sessions with SSL information.
To use SSL information, turn on Enable SSL ID tracking in the session management property page. Because the SSL session ID is negotiated between the web browser and HTTP server, this ID cannot survive an HTTP server failure. However, the failure of an application server does not affect the SSL session ID if an external HTTP server is present between WebSphere Application Server and the browser.
SSL tracking is supported for the IBM HTTP Server and iPlanet Web Servers only. We can control the lifetime of an SSL session ID by configuring options in the web server. For example, in the IBM HTTP Server, set the configuration variable SSLV3TIMEOUT to provide an adequate lifetime for the SSL session ID. An interval that is too short can cause a premature termination of a session. Also, some web browsers might have their own timers that affect the lifetime of the SSL session ID. These web browsers may not leave the SSL session ID active long enough to serve as a useful mechanism for session tracking. The internal HTTP Server of WAS also supports SSL tracking.
When using the SSL session ID as the session tracking mechanism in a cloned environment, use either cookies or URL rewriting to maintain session affinity. The cookie or rewritten URL contains session affinity information that enables the web server to properly route a session back to the same server for each request.
Related tasks
Reference topic