WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

962 WebSphere Application Server V8.5 Administration and Configuration Guide for the Full Profile

28.1 Session overview

In many web applications, user choices or actions determine where the user is sent next, how

the application behaves, or what the page displays. For example, if the user clicks a checkout

button on a site, the next page must contain the user’s shopping choices and information. The

Java servlet specification provides a mechanism for servlet applications to maintain a user’s

state information. This mechanism, is known as a

session. Sessions allow applications,

running in a web container, to keep track of individual users.

A servlet distinguishes users by their unique session IDs. The session ID is stored as a

cookie or alternatively can be conveyed to the servlet by URL rewriting.

28.1.1 Session identifiers

WebSphere Application Server passes the user an identifier known as a session ID, which

correlates an incoming user request to a session object that is maintained on the server. The

session ID arrives with each request.

There are three approaches used in WebSphere Application Server for tracking sessions:

 Cookies

 URL rewriting

 SSL session identifiers (deprecated)

Cookies

WebSphere Application Server session support generates a unique session ID for each user

and returns this ID to the user’s browser with a cookie, as illustrated in Figure 28-1. The

default name for the session management cookie is

JSESSIONID.

Figure 28-1 Cookies overview

Note: In accordance with the Servlet 2.3 API specification, the session management

facility supports session scoping by web modules. Only servlets in the same web module

can access the data associated with a particular session. Multiple requests from the same

browser, each specifying a unique web application, result in multiple sessions with a

shared session ID. You can invalidate any of the sessions that share a session ID without

affecting the other sessions.

Deprecated feature: Session tracking using the SSL ID is deprecated in WebSphere

Application Server 7.0. You can configure session tracking to use cookies or URL rewriting.

Browser's cookie list

Session cache

JSESSIONID: 123

JSESSIONID: 123

Counter: 5

Age: 35

Salary: ...

JSESSIONID: 123

WebSphere Application Server

User

JSESSIONID: 123

Chapter 28. Session management 963

A cookie consists of information that is embedded as part of the headers in the HTML stream

passed between the server and the browser. The browser holds the cookie and returns it to

the server whenever the user makes a subsequent request. By default, WebSphere defines

its cookies so they are destroyed if the browser is closed.

The web application developer uses the HTTP request object’s standard interface to obtain

the session, as shown in Example 28-1.

Example 28-1 Get the HTTP session object

//Suppose HttpServletRequest request has been initiated.

HttpSession session = request.getSession(true);

String sessionID = session.getId();

WebSphere places the user’s session identifier in the outbound cookie when the servlet

completes its execution, and the HTML response stream returns to the user.

URL rewriting

A typical usage of URL rewriting is configuring session tracking for Wireless Application

Protocol (WAP) devices. Because most WAP devices do not support cookies, you can

configure these devices to use URL rewriting to track sessions. URL rewriting requires the

developer to perform the following actions:

 Use special APIs to encode the URLs.

 Set up the site page flow to avoid losing the encoded information.

Program session servlets to encode URLs

URL rewriting works by storing the session identifier in the page that is returned to the user.

WebSphere Application Server encodes the session identifier as a parameter on URLs that

are encoded programmatically by the web application developer. Example 28-2 shows a web

page link with URL encoding.

Example 28-2 Web page link with URL encoding

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

When the user clicks this link to move to the /store/catalog page, the session identifier is

passed in the request as a parameter.

If the servlet returns HTML directly to the requester, without using

JavaServer Pages (JSP),

the servlet calls the API, as shown in Example 28-3, to encode the returning content.

Example 28-3 URL encoding from a servlet

//Suppose HttpServletResponse response has been initiated.

out.println("<a href=\");

out.println(response.encodeURL ("/store/catalog"));

out.println("\>catalog</a>");

The pages using redirection, servlet, or JSP must encode the session ID as part of the

redirection, as shown in Example 28-4.

Example 28-4 URL encoding with redirection

//Suppose HttpServletResponse response has been initiated.

response.sendRedirect(response.encodeRedirectURL("http://myhost/store/catalog"));