Session Management in Java Web Apps

Today, we're going to walk through how session management works in the context of Java web applications. In order to see how the flow works, we'll start with this diagram, which we'll explain in more detail below.

1. The user requests a webpage.
2. The 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, the 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 another (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 in two 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?

One of two 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 the user either closes the browser or leaves it open without any activity.
2. Explicit logout pages: Servlets/JSPs can invalidate the session using 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 that 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 will work as long as the session has not timed out. This also poses a security risk (if someone else knows 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). This is one of the reasons why cookies are preferred over URL rewriting.