Session Tracking

HTTP is, by design, a stateless protocol. Many web applications require that a series of requests from a client be associated with one another. For example, an online store will need to maintain the state of a user's shopping cart across HTTP requests. The HttpSession object allows servlets and JSPs to manage client-specific state on the server. You can associate object-valued attributes to the HttpSession by name. Any object bound to the session is available to any other servlet within the same servlet context. You can even declare JavaBean components within JSPs that have session-wide scope.

In order to implement server-side HTTP sessions, WebLogic needs to associate session data across browser requests with the same client. This is done by associating a unique tag (called the session ID) with every client, and ensuring that this tag is transferred with every request. The mechanism by which WebLogic binds the client to its session data is called session tracking. WebLogic supports two mechanisms for tracking session-state information: cookies and URL rewriting.

2.5.1 Session Tracking with Cookies

Every J2EE-compliant servlet engine is required to support session tracking using cookies. When an HttpSession is created, a unique ID is associated with it. WebLogic then attempts to store the session ID by sending a cookie back to the client. Once a cookie is set, the browser will return the cookie on each subsequent request. The server then is able to parse the cookie and return the associated session object when you invoke the getSession( ) method on the servlet. The servlet specification demands that this session-tracking cookie be named JSESSIONID.

2.5.1.1 Using cookies with SSL

Requests sent using HTTP and HTTPS use different ports, and some browsers treat the same address with different ports as two different locations. Hence a cookie created using one port may not be associated with the cookie using the other port. As a result, you may find new sessions being created when browser requests alternate between the HTTP and HTTPS protocols. To get around this problem, you need to configure the CookieDomain parameter within the session-descriptor element in the weblogic.xml descriptor file:

 
 CookieDomain
 domainname.com
 

The browser will then be instructed to include the proper cookies for all requests to the web application under any of the hosts in the domain domainname.com

2.5.2 Session Tracking with URL Rewriting

URL rewriting is an alternate mechanism for session tracking. If the client browser does not accept cookies, you must encode the session ID into all URLs sent back to the client through the response stream. The encodeURL( ) method on the HttpServletResponse object allows you to encode the session ID into a URL as a path parameter. The servlet specification demands that the session ID parameter have the name jsessionid. For example, the URI /catalog/index.html could be encoded as http://www.myserver.com/catalog/index.html;jsessionid=1234. This means that when a client browser requests a web resource using the encoded URL, WebLogic extracts the session ID from the URL and fetches the associated session object.

To ensure your code handles URL rewriting properly, you must encode all URLs sent back to the client:

out.println("<a href="">Catalog Index</a>");

However, WebLogic detects whether the client supports cookies before encoding URLs. So, the encodeURL( ) method leaves the URL unchanged if the client does accept cookies. Likewise, when you redirect to another servlet or JSP, you must encode the target URL as well:

if (loggedin) {
 response.sendRedirect(response.encodeRedirectURL("/welcomeUser.jsp"));
}

Regardless of the settings, WebLogic automatically uses URL rewriting when creating a new session because the server needs more than one visit to ensure that the client supports cookies. Servlets can determine whether the session ID came from a cookie or a URL by invoking the isRequestedSessionIdFromCookie( ) method on the HttpServletRequest object.

You can disable URL rewriting explicitly by setting the UrlRewritingEnabled session parameter to false. This session parameter is defined within the session-descriptor element in the weblogic.xml descriptor file:

 
 UrlRewritingEnabled
 false
 

By default, URL rewriting is enabled for all web applications in WebLogic Server.

2.5.2.1 URL rewriting for WAP

The WAP protocol does not support cookies, so URL rewriting must always be used if the web application needs to cater to WAP-enabled browsers. Additionally, many WAP devices have a limit on the length of the URL. To cater for this, you can set the IDLength parameter in the session-descriptor element:

IDLength 104

This value for the IDLength parameter defaults to 52, and can range from 8 to Integer.MAX_VALUE.

2.5.3 Session Security and Single Sign-on

Once a client has authenticated itself with a web server, the user is associated with both session data and authentication data. The authentication data is stored both as part of the user's session and as part of the server context. This authentication information can persist independent of the session data. Therefore, in order to effectively log the user out of the web server, you need to remove his authentication and session data. If the user is logged in to a single web application, you could invoke invalidate( ) on the user's HttpSession object, effectively logging the user out of the web server. If a web client can log into multiple web applications, you will need to invalidate all of the user's active sessions and remove the user's authentication data from the web server.

WebLogic permits a single sign-on for multiple web applications. This means that once a client has authenticated itself to the web server, the user has access to all web applications running on the server. When a user leaves a web server or "logs off" from one of the web applications, you want to be able to invalidate all his active sessions and remove his authentication data. We need a single sign-off so that after a client logs off, the user cannot access any of the web applications unless he authenticates himself again. The servlet specification provides no mechanism for this. However, WebLogic Server does.

The weblogic.servlet.security.ServletAuthentication class allows you to effectively log a client out of all web applications:

logout(HttpServletRequest req)

The logout( ) method removes authentication data associated with a client from the web server and all active sessions the user has logged into. The session associated with the user remains alive.

invalidateAll(HttpServletRequest req)

The invalidateAll( ) method invalidates all the sessions associated with the user and removes the authentication data. Because the cookie binding the user to the session is no longer needed, the cookie is invalidated too.

killCookie(HttpServletRequest req)

The killCookie( ) method invalidates the current cookie, ensuring that it expires as soon as the response is sent back to the client. The session will remain active until it times out. Note that for this to successfully invalidate the cookie, the browser must receive the response holding the invalidated cookie.

2.5.3.1 Avoiding single sign-on

As you can see from the previous discussion, the single sign-on mechanism is the default mechanism in WebLogic all web applications will share the security data. If you do not want a web application to participate in the single sign-on facility, you can specify a different cookie name for the session-tracking cookie. By changing the value of the CookieName parameter within the session-descriptor element in the weblogic.xml descriptor file, you can ensure that the client is always required to sign on and authenticate itself when it visits a servlet, JSP, or any static resource that belongs to the web application.