For a single user application, like a desktop application, there is only one user, so there is also one session, it is not difficult for the application to make the connection between the user and their session data. However, for a web application, a server has multiple clients, how does it know which session is yours? That’s where the session id comes into play.

The general principle is that you, as the client, give the server your session id, and in return the server grants you access to your session data if it finds your session id stored in its session datastore. The session structure is like a data locker for users, and the key for the locker is the session id, the server is the guy who shows you which one is your locker.

Session work flow

In general when a user makes an attempt to login into his account, servlet checks user’s login credentials. If the credentials are correct, then server creates a session for the user along with the response. This session will exist till it’s life span gets expired or till the user selects logout option.

The above figure depicts how a session works. Whenever a client makes a request, a session gets created for that client. The session id is a unique id by using which client  can track his session. The session will have a life time and it gets expired immediately after its life time gets completed.

In the above figure, there are two clients who are requesting the servlet for a service. The servlet verifies the request and provides response along with a session to the client. The session can be identified with a session id. Here, two different session ids are created one for each client.

Creating a session:

A session can be created using the following syntax,

HttpSession session=request.getSession();

user can set maximum lifetime of session using set method.

How a session expires?

Some scenarios in which the session gets expired are:

  • When user  selects logout option.
  • When server is stopped.
  • When lifespan of session gets completed.
  • when cookies are disabled in browser.
  • user can call invalidate() method to kill a session.

Problem with HTTP:

HTTP is a “stateless” protocol which means that  each time a client retrieves a Web page,  a new session gets created. This is not a good practice, so to overcome this problem a method is used which is called as session management.

Session Management:

Session management  is a mechanism used by the web container to store session information for a particular user. There are four different techniques used by servlet application for session management.

They are:

  1. Cookies :

Cookies are small piece of information that are sent in response form the web server to the client. Cookies are the simplest technique use for storing client state.
Cookies are stored on client’s computer. They have a lifespan and are destroy by the client browser at the end of that lifespan. There are two types of cookies.

They are :

  • Non-persistent cookie ( valid for single session )
  • Persistent cookie ( valid for multiple sessions )

2. HTTP session :

HTTP Session object is used to store entire session with a specific client. We can store, retrieve and remove
attribute from HttpSession object. Any servlet can have access to HttpSession object through the
getSession() method of the HttpServletRequest object.

3. URL rewriting :

If the client has disabled cookie in the browser then session management using cookie wont work. In that case URL rewriting can be used as a backup. URL rewriting will always work.
In URL rewriting, a parameter is added at the end of the URL. The parameter consist of key,value pair
separated by an equal sign.

For example,

“index ? id = sample@gmail.com”

Here ‘id’ is a parameter name and ‘sample@gmail.com’ is parameter value.

4. Hidden form field

Hidden form field can also be used to store session information for a particular client. In case of hidden form field a hidden field is used to store client state.
In this case user information is stored in hidden field value and retrieve from another servlet.

 Session Replication

Session replication ensures that client sessions of distributable applications are not disrupted by failovers by nodes in a cluster. Each node in the cluster shares information about ongoing sessions, and can take them over if the originally-involved node disappears.

Session replication is a mechanism used to replicate the data stored in a session across different instances. However, the replicated instance must be part of the same cluster. When session replication is enabled in a cluster environment, the entire session data is copied on a replicated instance.

In order to test session replication, we need to use multiple tomcat servers, load balance. Start multiple tomcat instances and deploy your application and run it in one server, then a session gets created in that particular server and is forwarded to all the other available servers.The request forward mechanism is handled by load balance and the response is provided to the client.

Converting HTTP Protocol to HTTPS

As we know that HTTP is a stateless and insecure protocol where data can be hacked easily, there is a need to provide security to our application and protect our data. For this reason there is a need for converting HTTP protocol to HTTPS. HTTPS stands for Hyper Text Transfer Protocol Secure. HTTPS is a secure version of HTTP. Here data communication between browser and server takes place in an encrypted format. This conversion needs an SSL(Secure Socket Layer) certificate which can be generated using following command:

[/crayon]
Then add the following code in server.xml file which is present in conf folder of tomcat.

[/crayon]
The above code is used for converting the generel HTTP port 8080  to 8443 which is HTTPS port. Now save the file and restart server and type ” https://localhost:8443/”, you will be directed to tomcat site.