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:

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:

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:

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 IDs1. 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.


If you enjoy this Java programming article, please share with friends and colleagues. Follow the author on Twitter for the latest news and rants.

Editorial page content written by Neil Coffey. Copyright © Javamex UK 2021. All rights reserved.