InfoCenter Home >
4: Developing applications >
4.4: Personalizing applications >
4.4.1: Tracking sessions >
4.4.1.1: Session programming model and environment >
4.4.1.1.1: Deciding between session tracking approaches

4.4.1.1.1: Deciding between session tracking approaches

Suppose a servlet implementing sessions is receiving requests from three different users. For each user request, the servlet must be able to figure out the session to which the user request pertains. Each user request belongs to just one of the three user sessions being tracked by the servlet. Currently, the product offers three ways to address the problem.

Cookies provide a fairly simple approach to tracking sessions. Because cookies do not work in all situations, URL rewriting provides an alternative. IBM WebSphere Application Server also provides a more secure mechanism for tracking sessions, through the use of a session ID that is derived from a unique identifier in SSL information. When deciding whether to use URL rewriting or SSL information, carefully review the coding requirements it imposes on applications that require session support.

Cookies

When session management is enabled and a client makes a request, the HttpSession object is created and the session ID is sent to the browser as a cookie. On subsequent requests, the browser sends the session ID back as a cookie and the Session Manager uses the cookie to find the HttpSession associated with the user.

URL rewriting

There are situations in which cookies will 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.

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:

<a href="/store/catalog">

is rewritten as:

<a href="store/catalog;jsessionid=DA32242SSGE2">

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

;jsessionid=DA32242SSGE2

as the session ID and saves it for obtaining the proper HttpSession object for this user.

Note: Do not make assumptions about the length or exact content of the ID that follows the equals sign (=). In fact, the IDs are longer than what this example shows.

To use URL rewriting, applications must follow certain coding guidelines. Also, special preparation is required. See the related information for details.

Secure Socket Layer (SSL)

For requests over SSL, SSL information is used to track session requests. When SSL session tracking is enabled for requests over SSL, SSL information is used as the session ID. SSL information takes precedence over cookies and URL rewriting. SSL session information cannot be shared between SSL and non-SSL requests.

When SSL is used as the tracking mechanism in a clustered environment, session affinity can be maintained through the use of cookies or URL rewriting. More specifically, the cookie or rewitten URL contains session affinity information that enables the session to be routed to the correct server in the cluster. (The application server uses a separate cookie that contains session affinity information.) The SSL ID is not sent in the cookie or rewritten URL but is derived from the SSL information.

Go to previous article: Session programming model and environment Go to next article: Using cookies to track sessions

 

 
Go to previous article: Session programming model and environment Go to next article: Using cookies to track sessions