108 lines
7.7 KiB
HTML
108 lines
7.7 KiB
HTML
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
||
|
|
<html>
|
||
|
|
<head>
|
||
|
|
<META http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<LINK rel="stylesheet" type="text/css" href="../../../rzahg/ic.css">
|
||
|
|
|
||
|
|
<title>Choose a session tracking method</title>
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<BODY>
|
||
|
|
<!-- Java sync-link -->
|
||
|
|
<SCRIPT LANGUAGE="Javascript" SRC="../../../rzahg/synch.js" TYPE="text/javascript"></SCRIPT>
|
||
|
|
|
||
|
|
<h4><a name="sesdeci"></a>Choose a session tracking method</h4>
|
||
|
|
|
||
|
|
<p>Suppose a servlet that implements HTTP sessions receives HTTP requests from three different clients (browsers). For each client request, the servlet must be able to determine the HTTP session to which the client request pertains. Each client request belongs to just one of the three client sessions being tracked by the servlet. Currently, the product offers three ways to track sessions:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li><a href="#cookies">With cookies</a></li>
|
||
|
|
<li><a href="#url">With URL rewriting</a></li>
|
||
|
|
<li><a href="#sslid">With SSL information</a></li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
|
||
|
|
<p><a name="cookies"></a><strong>Cookies</strong></p>
|
||
|
|
|
||
|
|
<p>Using cookies is the simplest and most common way to track HTTP sessions, because it requires no special programming to track sessions. When session management is enabled and a client makes a request, the HttpSession object is created and a unique session ID is generated for the client and sent to the browser as a cookie. On subsequent requests to the same hostname, the browser continues to send the same session ID back as a cookie and the Session Manager uses the cookie to find the HttpSession associated with the client.</p>
|
||
|
|
|
||
|
|
<p><a name="url"></a><strong>URL rewriting</strong></p>
|
||
|
|
|
||
|
|
<p>There are situations in which cookies do not work. Some browsers do not support cookies. Other browsers allow the user to disable cookie support. In such cases, the Session Manager must resort to a second method, URL rewriting, to manage the user session.</p>
|
||
|
|
|
||
|
|
<p>With URL rewriting, links returned to the browser or redirect have the session ID appended to them. For example, the following link in a Web page: </p>
|
||
|
|
<pre> <a href="/store/catalog"></pre>
|
||
|
|
|
||
|
|
<p>is rewritten as:</p>
|
||
|
|
|
||
|
|
<pre> <a href="store/catalog;jsessionid=DA32242SSGE2"></pre>
|
||
|
|
|
||
|
|
<p>When the user clicks the link, the rewritten form of the URL is sent to the server as part of the client's request. The Web container recognizes <tt>;jsessionid=DA32242SSGE2</tt> as the session ID and saves it for obtaining the proper HttpSession object for this user.</p>
|
||
|
|
|
||
|
|
<p><strong>Note:</strong> Do not make assumptions about the length or exact content of the ID that follows the equals sign (=). In fact, the IDs are often longer than what this example shows.</p>
|
||
|
|
|
||
|
|
<p>An application that uses URL rewriting to track sessions must adhere to certain programming guidelines. The application developer needs to:</p>
|
||
|
|
|
||
|
|
<ul>
|
||
|
|
<li>Program session servlets to encode URLs</li>
|
||
|
|
<li>Supply a servlet or JSP file as an entry point to the application</li>
|
||
|
|
<li>Avoid using plain HTML files in the application</li>
|
||
|
|
</ul>
|
||
|
|
|
||
|
|
<p><strong>Program session servlets to encode URLs</strong></p>
|
||
|
|
<p>Depending on whether the servlet is returning URLs to the browser or redirecting them, include either the encodeURL() or encodeRedirectURL() method in the servlet code. Here are examples demonstrating what to replace in your current servlet code.</p>
|
||
|
|
|
||
|
|
<p><strong>Rewrite URLs to return to the browser</strong></p>
|
||
|
|
|
||
|
|
<p>Suppose you currently have this statement: </p>
|
||
|
|
<pre> out.println("<a href=\"/store/catalog\">catalog<a>");</pre>
|
||
|
|
<p>Change the servlet to call the encodeURL method before sending the URL to the output stream:</p>
|
||
|
|
<pre> out.println("<a href=\"");
|
||
|
|
out.println(response.encodeURL ("/store/catalog"));
|
||
|
|
out.println("\">catalog</a>");</pre>
|
||
|
|
|
||
|
|
<p><strong>Rewrite URLs to redirect</strong></p>
|
||
|
|
<p>Suppose you currently have the following statement: </p>
|
||
|
|
<pre> response.sendRedirect ("http://myhost/store/catalog");</pre>
|
||
|
|
<p>Change the servlet to call the encodeRedirectURL method before sending the URL to the output stream:</p>
|
||
|
|
<pre> response.sendRedirect (response.encodeRedirectURL
|
||
|
|
("http://myhost/store/catalog"));</pre>
|
||
|
|
|
||
|
|
<p>The encodeURL() and encodeRedirectURL() methods 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, they return the original URL.</p>
|
||
|
|
|
||
|
|
<p>If both cookies and URL rewriting are enabled and response.encodeURL() or encodeRedirectURL() is called, the URL is encoded, even if the browser making the HTTP request processed the session cookie.</p>
|
||
|
|
|
||
|
|
<p>You 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.</p>
|
||
|
|
|
||
|
|
<p><strong>Supply a servlet or JSP file as an entry point</strong></p>
|
||
|
|
|
||
|
|
<p>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 must be encoded in order to perpetuate the session ID for the servlet (or other application component) requiring the session support.</p>
|
||
|
|
|
||
|
|
<p>The following example shows how Java code can be embedded within a JSP file:</p>
|
||
|
|
<pre> <% response.encodeURL ("/store/catalog"); %></pre>
|
||
|
|
|
||
|
|
<p><strong>Avoid using plain HTML files in the application</strong></p>
|
||
|
|
|
||
|
|
<p><strong>Note:</strong> To use URL rewriting to maintain session state, do not link to parts of your applications from plain HTML files (files with .html or .htm extensions).</p>
|
||
|
|
|
||
|
|
<p>The restriction is necessary because URL encoding cannot be used in plain HTML files. To maintain state using URL rewriting, every page that the user requests during the session must have code that can be understood by the Java interpreter. </p>
|
||
|
|
|
||
|
|
<p>If you have plain HTML files in your application (or Web module) or in portions of the site that the user might access during the session, convert the files to JSP files. </p>
|
||
|
|
|
||
|
|
<p>This impacts the application writer because maintaining sessions with URL rewriting requires that each servlet in the application must use URL encoding for every HREF attribute on <A> tags, as described previously. </p>
|
||
|
|
|
||
|
|
<p>Sessions are lost if one or more servlets in an application do not call the encodeURL(String url) or encodeRedirectURL(String url) methods.</p>
|
||
|
|
|
||
|
|
<p><a name="sslid"></a><strong>Session tracking with SSL information</strong></p>
|
||
|
|
|
||
|
|
<p>No special programming is required to track sessions with Secure Sockets Layer (SSL) information.</p>
|
||
|
|
|
||
|
|
<p>To use SSL information, select <strong>Enable SSL ID tracking</strong> in the Session Management page of the administrative console. Because the SSL session ID is negotiated between the Web browser and HTTP server, this ID cannot survive an HTTP server failure.</p>
|
||
|
|
|
||
|
|
<p>SSL tracking is supported by the IBM HTTP Server only. You 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 WebSphere Application Server - Express also supports SSL tracking.</p>
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|
||
|
|
|