Introduction | Servlets & HTTP | Life-Cycle | Sessions | Summary | Examples

Sessions: HTTP Session Tracking | Cookies | Servlet Sessions | Sessions At Work

Session Tracking with HTTP

The Remote User

Most of the time when your surfacing the Internet, your doing it anonymously; the server doesn't care who you are and you don't have the time or inclination to make yourself know to the server. This is nice and the default working model for the web. However, sometimes a server wants to publish information on the web for a specific group of users or user. As a surfacer, you are known as a REMOTE_USER to the server. Using HTTP authentication, when you try to access a restricted web resource, the browser forces you to enter a username and password. Upon successful authentication, REMOTE_USER is set to the username you used to login with. Now the server has an identifier that can be used to maintain a session with you and your browser.

HTTP Authentication Dialog

HTTP authentication using REMOTE_USER is simple to implement and check for within a servlet as it is just a parameter passed along with the HTTP request:

String user = request.getRemoteUser();
if( user == null )
  // not HTTP authenticated
else
  // welcome 'user'

Here getting the remote user is just a call to getRemoteUser() off the HTTPSerlvetRequest object. If the user has not been HTTP authenticated the value is null, otherwise the username is returned.

That said, who wants to be logging into a every web site they visit and having to remember hundreds of passwords. Normally you login for restricted resources, not so that the web server can identify you and maintain simple sessions. Furthermore, HTTP authentication can be for groups of users, requiring extra logic to be in place to enforce unique sessions for users within the group. And finally, once you've been HTTP authenticated, it is browse-dependent as to whether the REMOTE_USER value will be passed along with each request. Given these shortcomings for the REMOTE_USER solution, even though its simple to implement at the server , it is unworkable from the client's perspective. What's needed is anonymous session tracking that is driven wholly from the server side.

Hidden Form Fields

Hidden form fields are bog standard HTTP tags that are use to store information in a form that is invisible to the user. In terms of session tracking, the hidden form field would be used to hold a client's unique session id that is passed from the client to the server on each HTTP request. This way the server can extract the session id from the submitted form, like it does for any of form field, and use it to identify which client is made the request and act accordingly. For example, using servlets we could submit following search form:

<form method="post" action="/servlet/search">
  <input type="text" name="searchtext">
  <input type="hidden" name="sessionid" value="23434abc">
  ...

</form>

When submitted to the servlet registered with the name search, it pulls out the sessionid from the form as follows:

public void doPost(HttpServletRequest request, HttpServletResponse response)
{
  ...
  String theSessionId = request.getParameterValue("sessionid");
  if( isAllowToPerformSearch(theSessionId) )
  {
    // has performed less than 10 searches

  } 
  ...

}

In the above logic, the search servlet gets the session id from the hidden form field and uses it to determine whether its allow to perform any more searches. In this case only 10 searches are allowed per session.

Hidden form fields implement the required anonymous session tracking features the client needs but not without cost. For hidden fields to work the client must allows send a hidden form field to the server and the server must always return that same hidden form field. This tightly coupled dependency between client requests and server responses requires sessions involving hidden form fields to be an unbreakable chain of dynamically generated web pages. If at any point during the session the client accesses a static page that is not point of the chain, the hidden form field is lost, and with it the session.

URL Rewriting

Instead of embedding session information within forms using hidden fields, URL rewriting stores session details as part of the URL itself. Let's take another look at how we request information for our search servlet:

[1] http://www.acknowledge.co.uk/servlet/search
[2] http://www.acknowledge.co.uk/servlet/search/23434abc
[3] http://www.acknowledge.co.uk/servlet/search?sessionid=23434abc

For the original servlet [1] the URL is clean. In [2] we have URL re-written it at the server to add extra path information as embedded links in the pages we send back to the client. When the client clicks on one of these links, the search servlet will do the following:

public void doGet(HttpServletRequest request, HttpServletResponse response)
{
  ...
  String sessionid = request.getPathInfo(); // return 2343abc from [2]
  ...
}

Extra path information work for both GET and POST methods in forms and outside of forms with static links.

Using technique [3] simply re-writes the URL with parameter information that can be accessed as follows:

      
request.getParameterValue("sessionid");

URL re-writing, like, hidden forms provides a means to implement anonymous session tracking. However, with URL rewriting you are not limited to forms and you can re-write URLs in static documents to contain the required session information. But URL re-writing suffers from the same major disadvantage that hidden form fields do, in that they must be dynamically generated and the chain HTML page generation cannot be broken. Furthermore, rewriting URLs is both tedious and error-prone.