Session Management in web applications: HttpServlets, Cookies

I have many colleagues, especially at initial stages of their carrier having lot of queries about session management, like

1.           How session management is done?
2.           What is actually sent in request by browser for session authentication?

I will try to explain the process and hopefully at the end, you will have these answers.

This article would require knowledge of Servlets. Please make sure you know the basics of servlets for better understanding.

Throughout the article I will use “user”, “browser” and “client” interchangeably, all have same meaning in our case.

Session Management

HTTP protocol is stateless by design and causes few problems. For example: If a user sends multiple requests from the same browser, the server cannot recognise if they are from same or different users. This would make the server’s job very difficult. For example, if data to be displayed is based on user’s previous response, server won’t be able to tell because it has no way to store data for current user.

I hope you can visualize the scenario, an easy one to think would be suppose user is asked for country. As soon as user clicks enter button, request goes to servlet to present a new page to get card details. After card details are submitted, user is asked for phone number, with ISD code already prefixed. Now, for server to return the right ISD code, it needs to know what country was selected by user, but there is no way to get this information because servlet is not storing any data for this user. I know this is not the best of example, you wouldn’t have this kind of application where you ask first the country name, then card detail and then phone number, but I hope this makes the problem statement clear.  See below:

So, we know the problem, but what is the solution?? You guessed it right, it’s HTTPSession.

HttpSession object holds the conversational state across multiple requests. In other words, for an entire session with that client.

Before we move further, let’s quickly take a look at how session work.

So, how does Session work?

Whenever request is made by client (browser in our case), container (tomcat for example) creates a new Thread to work on the servlet, creates a request and response object and passes them to the servlet. But that is not all what container does! For the first request from a user (browser in our case), container also creates session with uniquely generated id and embed it in the request object. Servlet can fetch the session from the request object passed to it by container and set values in the session. When response is sent back, session ID is passed along in the response headers. For subsequent request from same user, session ID is also passed to the container which gets the corresponding session, add reference of it to the request and pass it to the servlet.

Session is shared across servlets and but not across different users.

To make it more clear, consider user1 makes request for servletA and there is code written in servletA to set “title” as “Java Territory” and save it in session.

Let’s see what happens if user2 also makes request for servlet A, and servletA tries to read “title” attribute from session, null will be returned as there are different session maintained by container for user1 and user2.

Now if user1 makes a new request (any servlet), it passes session ID alongside in the request headers, container sees the session ID, fetches corresponding session and attach it to the request object.

There the next question comes, where was session ID saved by the client (browser in our case) when response came for the first request from the server.

Answer is Cookies.

On first request from a client, container creates a session and sends the session ID in response headers back to the browser. When browser sees the session ID, it stores it with JESSIONID attribute in cookies. You can see this in the browser devloper tools.

If you manually copy the cookies from one browser/system to another, you can login to the same session. Hence security is the utmost concern here. Anybody can inject some JavaScript in your browser which can steal cookies information. For this reason, session cookies are http-only cookies (please see the check against http in above diagram). Http-only cookies are the one which cannot be accessed by client-side APIs, such as JavaScript. This eliminates the threat of cross-site-scripting (XSS).

So that’s it on basics the session management. There is more to it if want to in depth, like:

• Session Migration,
• Session listeners, 
• Types of cookies, and more...

I will cover these topics in upcoming article. Please like/share if liked the article and follow us at +Java Territory to stay updated with latest articles.

Thanks for reading.