Session tracking is the process of maintaining information, or state, about Web site visitors as they move from page to page. It requires some work on the part of the Web developer since there's no built-in mechanism for it. The connection from a browser to a Web server occurs over the stateless Hypertext Transfer Protocol (HTTP).

There are a number of ways to handle session tracking, but our focus is on the easy-to-use yet powerful HttpSession interface provided by the Java Servlet specification. Before we get into the HttpSession interface, let's look at some other ways of maintaining state.

Session-Tracking Techniques
At one time Web developers used Web site visitors' IP addresses to track the sessions. This approach was inflexible and had many flaws. The main problem was that proxy servers eliminated the use of individual IP addresses. Users no longer had unique addresses, so this technique couldn't work properly. Another way of handling session tracking is the use of the HTML hidden field:

<INPUT TYPE="hidden" NAME="user"VALUE="Jennifer">

This technique required server-side scripting that would dynamically generate the HTML code that contained the "user" field. Server-side code was also required to read the field and match it to information about this user on the server.

Another session-tracking technique is URL rewriting. In this approach, identification field(s) are appended to the end of each URL for a Web site. The following HTML code demonstrates this method:

<A HREF="/orderform.htm?user=Jennifer">Order Now!</A>

This approach is similar to hidden fields. The difference is that hidden fields can only be used in a form.

A common way of session tracking is the use of cookies. A cookie is information that's stored as a name/value pair and transmitted from the server to the browser. Cookies containing unique user information can be used to tie specific visitors to information about them on the server. The Java Servlet specification provides a simple cookie API that allows you to write and retrieve cookies. The complete API can be found on Sun's Java Web site, http://java.sun.com. The following code shows how to create a new cookie:

Cookie user = new Cookie("user","Jennifer");
user.setMaxAge(3600);
response.addCookie(user);

This code creates a cookie with a name of "user" and a value of "Jennifer". The cookie's expiration date is set with the setMaxAge() method to 3,600 seconds from the time the browser receives the cookie. The following code demonstrates how you would retrieve the value for a specific cookie:

String user = "";
Cookie[] cookies = request.getCookies();
if (cookies != null) {
for (int i = 0; i < cookies.length; i++) {
if (cookies[i].getName().equals("user")) user =
cookies[i].getValue();
}
}

In this code, an array of cookies is retrieved from the HttpServletRequest object using the getCookies() method. The array is walked through until a cookie with the name of "user" is returned by the getName() method. Once the cookie is found, the getValue() method is called to retrieve the value of the cookie.

The use of cookies provides a flexible and easy option for handling session tracking; however, it does present some problems. The information in the cookie is stored on the client's browser in a text file that can be easily read and manipulated, and this information is transmitted unsecured across the Internet. But the main problem is that they can be disabled through a setting in the Web browser. Web sites that rely on cookies for session tracking will be unable to track users who have disabled cookies.

Sessions in Java
The session management techniques we have looked at so far all have a common security issue: they transmit data in plain text. A powerful session-tracking solution is needed that's more secure and flexible. This is where the Java HttpSession API comes in. The HttpSession API provides a simple mechanism for storing information about individual users on the application server. The API provides access to a session object that can be used to store other objects. The ability to tie objects to a particular user is important when working in an object-oriented environment. It allows you to quickly and efficiently save and retrieve JavaBeans that you may be using to identify your site's visitors, to hold product information for display on your online store, or to track products that potential customers have placed in their shopping carts.

A session object is created on the application server, usually in a Java servlet or a JavaServer Page. The object is stored on the application server and a unique identifier called a session ID is assigned to it. The session object and session ID are handled by a session manager on the application server. Figure 1 illustrates this relationship. Each session ID assigned by the application server has zero or more key/value pairs tied to it. The values are objects that you place in the session. Assign each of those objects a name, and each name must have an object with it because a null is not allowed.

Figure 1

For this session-tracking technique to work, the session ID must be sent to the client's computer. A cookie is used to store the session ID on the Web site visitor's computer. This is automatically handled by the application server. Simply create the session object and begin using it. The application server will, by default, create the session ID and store it in a cookie. The browser will send the cookie back to the server every time a page is requested. The application server, via the server's session manager, will match the session ID from the cookie to a session object. The session object is then placed in the HttpServletRequest object and you retrieve it with the getSession() method.

As we discussed earlier, some Web site visitors will have cookies disabled in their browsers. To get around this problem and continue using sessions, use URL rewriting in your code. URL rewriting appends the session ID to the URL for every page that's requested. The only problem here is that you must rewrite every link in your HTML code as well as those from servlet to servlet, or servlet to JSP.

The procedure for URL rewriting is quite simple and requires only the use of two methods found in the HttpServletResponse interface. These two methods, encodeURL() and encodeRedirectURL(), are used to append the session ID to the URL. This allows the server to track users as they move through your Web pages, but it requires that every URL be rewritten. The string returned by the methods will have the session ID appended to it only if the server determines that it's required. If the user's browser supports cookies, the returned URL will not be altered. Also, the returned URL won't be altered if the application server is configured to not use URL rewriting. The format of the altered URL will vary based on different application server implementations; however, the common format will be the addition of a parameter, such as "sessionID=uniqueIDnumber". The parameter name (in this case "sessionID") is usually controlled through a configuration setting on the server. The value of the parameter ("uniqueIDnumber" in this example) is the unique session ID assigned by the server's session manager and is a long series of letters and numbers. The following line of HTML code from a JSP creates a link to another JSP:

<A HREF="/products/product.jsp">Product Listing</A>

Clicking on this link would send the user to the product.jsp page. Using URL rewriting, the same code would be written as follows:

<A HREF="<%= response.encodeURL("/products/product.jsp")
%>">Product Listing</A>

The returned string from the encodeURL() method would contain the session ID. On a Tomcat 3.2 application server, the result of this line of code would be:

<A HREF="http://www.yourservername.com/products/
product.jsp;$sessionid$xxxx">Product Listing</A>

The xxxx would actually be a unique session ID generated by the server. The other method you can use for rewriting URLs is the encodeRedirectURL(). It's used only in a servlet or JSP that calls the sendRedirect() method of the HttpServlet-Response interface. The following code is a standard redirection statement:

response.sendRedirect("http://www.yourservername.com/
products/sale.jsp");

Using URL rewriting, the code would be:

response.sendRedirect(response.encodeRedirectURL(
"http://www.yourservername.com/products/sale.jsp"));

The application server handles the encodeRedirectURL() method a little differently than the encodeURL() method; however, each method produces the same result.

You should now have a good understanding of how the session ID is tracked and matched to a session object on the server. The first step in using the session object is creating it. The method getSession() is used to create a new session object and to retrieve an already existing one. The getSession() method is passed a Boolean flag of true or false. A false parameter indicates that you want to retrieve a session object that already exists. A true parameter lets the session manager know that a session object needs to be created if one does not already exist. The following line of code demonstrates the use of getSession():

HttpSession session = request.getSession(true);

The getSession() method will return the session object. A new session object is created if one does not already exist. The server uses the session ID to find the session object. If a session ID is not found in a cookie or the URL, a new session object is created. You would probably use only the getSession() method with a true parameter at one point in your Web application. This would be the starting point of your site, possibly after the visitor has successfully logged in. Other servlets in your application should use the getSession(false) method. This will return a current session object or null. It does not generate a new session if one doesn't already exist.

A number of methods are defined in the Java Servlet specification. (A complete API can be found on http://java.sun.com.) The methods you'll use most often and the ones we'll focus on are: