This chapter is from the book
This chapter is from the book
This chapter is from the book
Session Tracking
In order to associate the user's session with a particular browser, WAS needs to maintain some form of association with the client browser. There are several techniques available, and we'll detail them here. It is important to note that while WAS allows for great flexibility in choosing the tracking mechanism, cookies are by far the best approach.
Cookies
The use of a cookie for tracking session state is the default in WAS. This option differs from a pure cookie-based solution in that the HTTP session uses a single cookie named JSESSIONID that contains the session ID, which is used to associate the request with information stored on the server for that session ID, while an entirely cookie-based solution would employ multiple cookies, each containing possibly sensitive user state information (account number, user ID, etc.). With HTTP session, all attributes associated with the user's request are stored on the server. Since the only information transmitted between the server and the browser is the session ID cookie, which has a limited lifetime, HTTP session can provide a much more secure mechanism than cookies for tracking application state when configured in conjunction with SSL.
The mechanics of using a cookie for tracking session are depicted in Figure 22-1. A request arrives at the server requiring that a session be created as the result of a getSession() method call. The server creates a session object, associating a session ID with it. The session ID is transmitted back to the browser as part of the response header and stored with the rest of the cookies in the browser. On subsequent requests from the browser, the session ID is transmitted as part of the request header, allowing the application to associate each request for a given session ID with prior requests from that user.
The interaction between browser, application server, and application are all handled transparently to the end user and the application program, aside from the getSession() method call inside the application. The application and the user need not be, nor are they likely aware of the session ID provided by the server.
)
Figure
22-1 Browser-session manager cookie interaction.
Unfortunately, not all users configure their browsers to accept cookies. Often, this is related to security concerns over accepting a cookie into the browser. Most often the restrictions on accepting a cookie into the browser are the result of concerns about persistent cookies. Persistent cookies remain in the browser after the browser is closed and allow a web site to "remember" you on ensuing visits. Most important in terms of presenting a risk, persistent cookies may contain personal information about you, which is then accessible to any application that has access to the cookie folder in your browser. However, WAS generates a session cookie that exists only until the browser has been closed and is used only to ensure that you are "recognized" as you move from page to page within the web site. This technique is not generally considered to be a security or privacy concern. In fact, most modern browsers can be configured to accept all session cookies while still blocking persistent cookies.
Finally, in a WAS environment with security enabled, disabling all cookies is actually counterproductive since the most often used authentication mechanism is LTPA (Lightweight Third Party Authentication), and LTPA relies on creating a token (cookie) that is used to represent the identity of the authenticated user to the browser. In any event, other options exist for maintaining an application state such as URL rewriting, although they are not recommended.
URL Rewriting
Most often, URL rewriting is employed when a browser is configured not to accept cookies. URL rewriting stores the session identifier in the page returned to the user. WAS encodes the session identifier as a parameter on any link or form the user submits from a web page. This option requires that the Servlet code be modified to include either an encodeURL() or encodeRedirectURL() method. When a browser user clicks on a link that utilizes one of these methods, the session identifier passes into the request as a parameter, with the result shown in Figure 22-2, where the session ID is appended to the URL for the web page.
){kind=small}
Figure
22-2 URL rewriting example in browser.
The requirement that the application developer write additional code for a Servlet or JSP presents a major disadvantage for URL rewriting when compared to other available session tracking mechanisms. Additionally, URL rewriting limits the flow of site pages exclusively to dynamically generated pages (those generated by Servlets or JSPs). While WAS can insert the session ID into dynamic pages, it cannot insert the user's session ID into static pages (.htm or .html pages). As a result, after the application creates the user's session data, the user must visit dynamically generated pages exclusively until he or she finishes with the portion of the site requiring sessions. URL rewriting forces the site designer to plan the user's flow in the site to avoid losing his or her session ID. Lastly, the system administrator must configure WAS to enable URL rewriting by checking the box shown in Figure 22-3.
){kind=small}
Figure
22-3 Session tracking mechanism dialog.
Fortunately, the WAS session management implementation can recognize when a browser is configured to accept cookies and will use this option instead of URL rewriting in cases when both cookies and URL rewriting are enabled.
SSL ID Tracking
Another alternative tracking mechanism is the Secure Socket Layer (SSL) ID that is negotiated between the web browser and the HTTP server. While secure, this alternative presents a number of disadvantages. Since this ID is negotiated between the browser and the HTTP server, the failure of the HTTP server results in the loss of this ID. In a clustered environment, the IP sprayer used to direct requests to the HTTP servers must provide some sort of affinity mechanism so that browser requests return to the HTTP server that negotiated the ID with the browser. Additionally, in a clustered environment with multiple application servers, either cookies or URL rewriting must be enabled for affinity between the HTTP server and application server. Lastly, in a fashion similar to URL rewriting, the administrator must also explicitly configure WAS to employ this option by selecting this option on the configuration dialog (refer to Figure 22-3).