How session management works in Java web applications (e.g. a Tomcat web application)

High-level Flow

Session Creation Flowchart
Session Creation Flowchart
  1. User requests a webpage
  2. Browser sends the request to the web-server
  3. The server sees that there is no “session related information/identifier” in the request. So it creates a new session (and a new session identifier – the JSESSIONID)
  4. The server sends the JSESSIONID back to the client (e.g. in a cookie, along with the main HTML response)
  5. At this point, both the server and the client have the same session identifier (JSESSIONID) with them
  6. From here on, when the browser sends additional requests to the server, it has to send the session identifier (JSESSIONID) as part of the request as-well (Note: whenever a browser sends a request to a web-server, all cookies set by the same server are automatically sent in the request. So, JSESSIONID cookie also gets sent to the server automatically)
  7. When the server gets a request, it checks if the browser sent a session identifier as part of the request. If yes, the server treats the request as part of the same session
  8. This handshake goes on until the session gets destroyed (or until it expires)

What if cookies are blocked?

At times, users/browsers may not accept cookies from certain servers (for security/privacy reasons). To deal with this case, web-servers also support passing the session identifier in the URL (URL rewriting)

  1. When the server creates a session, it “has to” send the session identifier to the client in some way or the other (so that the client can then send it back to the server during subsequent requests)
  2. Initially, the server doesn’t know if the client has blocked cookies or not. So it sends the JSESSIONID to the client using 2 ways –
    1. In a cookie
    2. As a URL parameter (e.g. http://www.abc.com;jsessionid=123xyz)
  3. When the server gets a subsequent request from the same client –
    • If the request contains the JSESSIONID cookie, it means that the client does accept cookies. So the server can rely on cookies for session management and continue
    • If not, the server understands that cookies are blocked and it continues to use the URL parameter approach (“URL rewriting”) NOTE: you have to take some steps to make sure this works correctly e.g. if your webpage has hyperlinks to other pages, you have to encode them using the response.encodeURL() method

How are sessions destroyed?

2 ways –

  1. Timeout – if the server doesn’t receive any requests for a given session within a certain period of time, it invalidates the session. This happens when user either closes the browser or leaves it open without any activity
  2. Explicit logout pages – servlets/JSPs can invalidate the session using code (session.invalidate())

What happens when the browser is closed?

  1. Cookie approach –
    • The JSESSIONID cookie is a “session only” cookie – so the browser deletes it as soon as the browser is closed. So if you open another window and visit the same web-app, the server would treat the request as a brand new request which is not part of any session
  2. URL rewriting approach –
    • If you copied the URL with the JSESSIONID, close the browser, open a new browser window and use the copied URL, it would work (As long as the session has not timed-out)
    • This is one of the reasons why cookies are preferred over URL rewriting
    • This also poses a security risk (if someone else gets to know the full URL with the JSESSIONID, they could use it, and if the session was still active, they could do stuff on behalf of someone else)

Found this useful? Please leave a Reply :)