Handling HTTP sessions from a Servlet

With a little bit of jiggery-pokery, it's possible for a web site to support sessions. That is, to remember things about the client between page requests. Sessions allow us to implement functionality such as:

• user logins and accounts for "privileged content";
• shopping carts;
• other cases where we need to "remember what the user entered before".

The basic premise of sessions is that only a session ID is stored on the client. On the server, that ID is associated with other "real world" information such as a user name, shopping cart etc. (This is a difference compared to using "raw" cookies to store information such as a user name on the client.) HTTP sessions typically operate is as follows:

• when a client first requests a page where we need to start a session (e.g. the "login" page), our server allocates a random session ID;
• that session ID is then communicated back to the client;
• whenever the client subsequently requests a page from our server (or relevant path from our server), it sends back the same session ID;
• on the server, we can associate information with that session ID;
• on the server, we can eventually decide that the session has "expired", and/or provide the user with a means to manually tell our server to "expire" the session.

Introducing the Servlet Session API

The Java Servlet framework provides an implementation of the above scheme in the form of the Session API. Using the session API generally solves various problems, including the following:

• how to transmit the session ID from server to client and vice versa;
• how to select secure session IDs;
• how to physically store associated objects/data with each session and check for session expiry.

Generally, transmitting the session ID to and from the server is handled via HTTP cookies, though other means are possible and could be chosen by Servlet implementations (e.g. rewriting URLs to contain the session ID as a parameter). Since there is notable paranoia around the use of cookies, it is at least better to use them within a standard API than to invent something likely to spur the more alarmist "anti-spyware" software into action.

Session ID security

What you may not have thought about initially is the problem of session ID security. It's generally important that valid session IDs can't be guessed by a rogue third party. For example, imagine if a banking site allocated its sessions sequentially. Then, suppose that a user logs on to the site and is given session number 763. That user could then guess that there's a fair chance that some other users are currently using sessions 761, 762, 764, 765 etc, change the session ID in their browser, and illegitimately access those other users' accounts. The same problem still occurs if we use some other easily-guessable formula or method for generating session IDs¹. The Session API should avoid this problem by generating "securely random" session IDs.

A problem that the session API doesn't solve per se is that session IDs are only transmitted securely if you explicitly use a secure connection (typically an HTTPS connection). For example, it isn't secure to (a) send a user name and password via an HTTPS connection; then (b) for the server to associate that user name/password with a session ID; and (c) send that session ID via a non-secure connection. If to the server the session ID is associated with a user name and password, then sending that session ID over a non-encrypted channel is just as insecure as sending the user name and password insecurely!

Using the Session API from a Servlet

On the next pages, we look at how to use the Session API from a Java Servlet.

---

1. For example, using a simple random number generator such as java.util.Random would not be secure enough, because given a couple of sample session IDs produced in succession, we could intuit the seed of the random number generator and guess subsequent IDs.

---