Servlet Session Tracking

1
Servlet Session Tracking
2
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

3
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 dont 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

4
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

5
Session tracking solutions

• Hidden ltformgt 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
• Javas Session Tracking API can be used to do
  most of the work for you

6
Hidden ltformgt fields

• ltinput type"hidden" name"sessionID" value"..."gt
  
• Advantages
• All you need to know is how to read servlet
  parameters
• String sessionID getParameter("sessionID")
• out.println("ltinput type\"hidden\" name\"session
  ID\" value\" sessionID
  "\"gt")
• Efficient Minimizes repeated calls to the server
• Disadvantages
• Information is lost when browser quits or goes to
  another page
• Useless for maintaining persistent information
  about a user
• Can be spoofed
• 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)--theyre
  simple and efficient

7
Using hidden ltformgt fields, I

• The very first request that the user sends you
  will (typically) have null for the value of your
  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
• Each subsequent request will include this hidden
  field
• 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 isnt coming back, and
  discard the session data

8
Using hidden ltformgt 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 ltformgt 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

9
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

10
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 cookiesi.getName()
• String value cookiesi.getValue()
• There are, of course, many more methods in the
  HttpServletRequest, HttpServletResponse,
  andCookie classes in the javax.servlet.http
  package

11
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

12
What cookies are good for

• Advantages
• Javas 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
• This saves space on the server
• May let you avoid keeping track of
  multiple(session) data structures
• Disadvantages
• Data is stored on the client computer, not on
  yours
• 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

13
Javas session tracking API, I

• Heres how you get a session ID from the request
• HttpSession session request.getSession()
• Heres what this does for you
• If the session includes a session ID cookie
  then find the session matching that session
  IDelse (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

14
Javas session tracking API, II

• Heres how you send a cookie in the response
• HttpSession session request.getSession()
• What this does for you
• 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

15
Using an HttpSession

• session.setAttribute(String name, Object value)
• You can save objects in an HttpSession
• object session.getAttribute(String name)
• You can retrieve your saved objects by name
• Enumeration e session.getAttributeNames()
• You can find the names of all your objects
• session.removeAttribute(String name)
• You can get rid of an object you no longer need
• boolean session.isNew()
• true if the session is newly created, rather than
  retrieved
• String id session.getId()
• You can get the session ID (if youre debugging,
  or just curious)

16
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!

17
URL rewriting

• If the user has cookies turned off, you can use
  URL rewriting
• URL rewriting is only used as a backup for
  cookies
• URL rewriting adds the session ID to the end of
  every URL
• URL jsessionid0ABCDEF98765
• This is almost automatic, but
• Cookies must fail, and
• You must explicitly encode (add the extra
  information to) your URLs, for example
• out.println("lta href\"" response.encodeURL(your
  URL) "\"gtclick melt/agt")

18
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 cant just send a cookie and see if
  it gets it back, because it cant 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

19
More HttpServletRequest methods

• public HttpSession getSession()
• Gets the session object for this request (or
  creates one if necessary)
• public Enumeration getHeaderNames()
• Gets an Enumeration of all the field names in the
  HTTP header
• public String getHeader(String name)
• Given the header name, return its value
• public int getIntHeader(String name)
• 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

20
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(you
  rURL)

21
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

22
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

23
The End