Servlet Session Tracking
Persistent information

A server site typically needs to maintain two kinds
of persistent (remembered) information:

Information about the session


A session starts when the user logs in or otherwise identifies
himself/herself, and continues until the user logs out or
completes the transaction (for example, makes a purchase)
Information about the user


User information must generally be maintained much longer
than session information (for example, remembering a
purchase)
This information must be stored on the server, for example on
a file or in a database
2
Server capabilities

Servlets, like Applets, can be trusted or untrusted





A servlet can use a unique ID to store and retrieve information about a
given session
User information usually requires a login ID and a password
Since servlets don’t quit between requests, any servlet can maintain
information in its internal data structures, as long as the server keeps
running
A trusted servlet can read and write files on the server, hence can maintain
information about sessions and users even when the server is stopped and
restarted
An untrusted servlet will lose all information when the servlet or server
stops for any reason


This is sometimes good enough for session information
This is almost never good enough for user information
3
Session tracking

HTTP is stateless: When it gets a page request, it has no
memory of any previous requests from the same client



This makes it difficult to hold a “conversation”
 Typical example: Putting things one at a time into a
shopping cart, then checking out--each page request must
somehow be associated with previous requests
The server must be able to keep track of multiple
conversations with multiple users
Session tracking is keeping track of what has gone
before in this particular conversation



Since HTTP is stateless, it does not do this for you
You have to do it yourself, in your servlets
You can do this by maintaining a session ID for each user
4
Session tracking solutions

Hidden <form> fields can be used to store a unique ID
for the session

Cookies are small files that the servlet can store on the
client computer, and retrieve later

URL rewriting: You can append a unique ID after the
URL to identify the user

Java’s Session Tracking API can be used to do most of
the work for you
5
Hidden <form> fields

<input type="hidden" name="sessionID" value="...">

Advantages:

All you need to know is how to read servlet parameters




Efficient: Minimizes repeated calls to the server
Disadvantages:



String sessionID = getParameter("sessionID");
out.println("<input type=\"hidden\" name=\"sessionID\" value=\" +
sessionID + "\">");
Not kept across sessions, so useless for maintaining persistent
information about a user
Since the session ID must be incorporated into every HTML page, every
HTML page must be dynamically generated
Hidden fields are good for session tracking (holding a
“conversation” with the user)--they’re simple and efficient
6
Using hidden <form> fields, I

The very first request that the user sends you will (typically)
have null for the value of your hidden field


Each subsequent request will include this hidden field



When your servlet sees the null, it can assign a unique session ID and
include it in a hidden field in the response
The servlet can keep session information in some data structure of its
own, keyed by the session ID
This is feasible because the servlet does not quit between requests, so it
can maintain information in its memory
You cannot assume the user will end the session the way you
think she should (say, by logging off)

If the session data is sufficiently “old,” you need to assume the user isn’t
coming back, and discard the session data
7
Using hidden <form> fields, II

The session ID does not have to be the only hidden field




You can have other fields in addition to, or instead of, a
session ID field
This might be a good way to keep track of small amounts of
simple information during a session
Hidden fields are not particularly well suited to holding
complex or structured information
In all cases, hidden <form> fields are good only for
storing session information

Information in servlet data structures will eventually be lost
(when the servlet quits) or get old and be discarded
8
Cookies

A cookie is a small bit of text sent to the client that can be read
again later

Limitations (for the protection of the client):





Not more than 4KB per cookie (more than enough in general)
Not more than 20 cookies per site
Not more than 300 cookies total
Cookies are not a security threat
Cookies can be a privacy threat



Cookies can be used to customize advertisements
Outlook Express allows cookies to be embedded in email
A servlet can read your cookies


Incompetent companies might keep your credit card info in a cookie
Netscape and Firefox let you refuse cookies to sites other than that to which
you connected
9
Using cookies



import javax.servlet.http.*;
Constructor: Cookie(String name, String value)
Assuming request is an HttpServletRequest and response
is an HttpServletResponse,
 response.addCookie(cookie);
 Cookie[ ] cookies = request.getCookies();



String name = cookies[i].getName();
String value = cookies[i].getValue();
There are, of course, many more methods in the
HttpServletRequest, HttpServletResponse, and
Cookie classes in the javax.servlet.http package
10
Some more Cookie methods


public void setComment(String purpose)
 public String getComment()
public void setMaxAge(int expiry)
 public int getMaxAge()




Max age in seconds after which cookie will expire
If expiry is negative, delete when browser exits
If expiry is zero, delete cookie immediately
setSecure(boolean flag)
 public boolean getSecure()

Indicates to the browser whether the cookie should only be sent using a
secure protocol, such as HTTPS or SSL
11
What cookies are good for

Advantages:



Java’s Session Tracking API (to be discussed) makes cookies dead
simple to use
Cookies can easily contain more data than hidden fields
Data is stored on the client computer, not on yours



Disadvantages:

Data is stored on the client computer, not on yours




This saves space on the server
May let you avoid keeping track of multiple(session) data structures
This means the data is neither safe nor secure
Should not be used for user data--cookies may be discarded or the user
may contact the server from another computer
Users can tell their browser to turn cookies off
Cookies are good for keeping session data, not user data
12
Java’s session tracking API, I

Here’s how you get a session ID from the request:


Here’s what this does for you:



HttpSession session = request.getSession();
If the session includes a session ID cookie
then find the session matching that session ID
else (no session ID cookie or no matching session)
create a new session
This method does all the cookie work for you
Whether the session is a new one or a pre-existing one,
you get an HttpSession for it
13
Java’s session tracking API, II

Here’s how you send a cookie in the response:


What this does for you:






HttpSession session = request.getSession();
Creates a new HttpSession object, or retrieves a previous one
Creates a unique session ID
Makes a new cookie object
Associates the cookie with the session ID
Puts the cookie in the response (under the Set-Cookie header)
Notice that:


This is exactly the same call as in the previous slide
The message is sent to the request, not the response
14
Using an HttpSession

session.setAttribute(String name, Object value)


object = session.getAttribute(String name)


You can get rid of an object you no longer need
boolean session.isNew()


You can find the names of all your objects
session.removeAttribute(String name)


You can retrieve your saved objects by name
Enumeration e = session.getAttributeNames()


You can save objects in an HttpSession
true if the session is newly created, rather than retrieved
String id = session.getId()

You can get the session ID (if you’re debugging, or just curious)
15
Quitting an HttpSession

session.invalidate()

Quits the session and unbinds any objects in it

milliseconds = session.getCreationTime()
 (since midnight January 1, 1970 GMT)
milliseconds = session.getLastAccessedTime()
 (again, since 1970)
session.setMaxInactiveInterval(int seconds)
 Sets the time until the session is automatically invalidated
int seconds = session.getMaxInactiveInterval()

So the Session API does nearly everything you need!



16
URL rewriting

If the user has cookies turned off, you can use URL
rewriting


URL rewriting adds the session ID to the end of every
URL:


URL rewriting is only used as a backup for cookies
URL + ;jsessionid=0ABCDEF98765
This is almost automatic, but:


Cookies must fail, and
You must explicitly “encode” (add the extra information to)
your URLs, for example:

out.println("<a href=\"" + response.encodeURL(yourURL) +
"\">click me</a>");
17
What the Container does

If you are using the Session API,




When the Container (Tomcat) starts a new session, it sends a
cookie and does URL rewriting
If it gets a cookie back, it abandons URL rewriting
The Container can’t just send a cookie and see if it gets
it back, because it can’t tell that what it gets back is
from the same session
A “dumb” Container may always send the cookie and
do URL rewriting each time
18
More HttpServletRequest methods

public HttpSession getSession()


public Enumeration getHeaderNames()


Given the header name, return its value
public int getIntHeader(String name)




Gets an Enumeration of all the field names in the HTTP header
public String getHeader(String name)


Gets the session object for this request (or creates one if necessary)
Given the header name, return its value as an int
Returns -1 if no such header
Could throw a NumberFormatException
public Enumeration getHeaders(String name)

Given the header name, return an Enumeration of all its values
19
Summary: Session Tracking API


The session tracking API is in javax.servlet.http.HttpSession and is
built on top of cookies
To use the session tracking API:
 Create a session:


HttpSession session = request.getSession();
 Returns the session associated with this request
 If there was no associated session, one is created
Store information in the session and retrieve it as needed:


session.setAttribute(name, value);
Object obj = getAttribute(name);

Session information is automatically maintained across requests

To allow URL rewriting, use response.encodeURL(yourURL)
20
Other uses of cookies




Cookies were devised for managing sessions, but you
can use them for other things
You can use cookies for storing small amounts of
information on your client computers
By default, cookies are discarded when the browser
quits
cookie.setMaxAge(int seconds)



If seconds is positive, cookie should persist for that long
If seconds is negative, cookie is deleted when browser quits
If seconds is zero, cookie is deleted immediately
21
Summary

A session is a continuous interaction with the user




HTTP is stateless, so the programmer must do something to
remember session information
There are multiple ways to remember session information
The session ends when the user quits the browser (or a session may
be set to time out)
Some information must be kept longer than just within a
session


For example, if the user orders a product, that information must be
kept in a database
Long-term storage of information requires that the servlet have
some additional privileges
22
The End
23