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