Session Management Design Notes in Servlet Containers

Servlet main description

A Servlet container is a container for running Java Servlets, which are part of a web server. It is responsible for handling Servlet's life cycle, request and response processing, multi-thread processing, session management and other tasks.

The following are the main design notes of the Servlet container architecture:

1. Servlet container architecture is usually designed based on layered structure. The lowest layer is the network layer, responsible for receiving and sending requests and responses. The middle layer is the container layer, which is responsible for handling the Servlet life cycle, request and response processing, and so on. The top layer is the Servlet API, which provides a programming interface for developers to use.
2. Servlet containers use thread pools to handle concurrent requests. When a request arrives, the container gets an idle thread from the thread pool to process the request. This improves performance and scalability.
3. The container maintains a pool of Servlet instances for each Servlet. These instances are created when the container starts and can be reused, reducing the overhead of creating and destroying Servlet instances.
4. The container is responsible for the lifecycle management of the Servlet. It creates a Servlet instance at startup, calls the Servlet's init() method for initialization, calls the Servlet's service() method when processing a request, and calls the Servlet's destroy() method for destruction when closing.
5. Containers are responsible for handling requests and responses. It receives requests from the network layer and encapsulates the requests into HttpServletRequest objects. Then, it passes the HttpServletRequest object to the Servlet's service() method for processing, and wraps the Servlet's response into an HttpServletResponse object and sends it back to the client.
6. The container is responsible for session management. It can track the user's session state, create and manage session objects, and provide APIs to store and retrieve session data.
7. Containers provide some auxiliary functions such as security, authentication and authorization, logging, error handling, etc.

Key points of session management

In the Servlet container, session management is an important component for tracking and managing the user's session state.

• Session ID (Session ID): The session ID is a unique value, usually stored in the client's Cookie. When a user initiates a session (such as logging in), the Servlet container will generate a unique session ID, store it in a cookie and send it to the client. The client will bring the cookie in subsequent requests, so that the Servlet container can identify and track the user's session according to the session identifier.
• Session life cycle management: The Servlet container will trigger a series of events for the life cycle of the session, including session creation, destruction and invalidation. When a user initiates a session (such as logging in), the Servlet container creates a new session and generates a unique session ID. The servlet container destroys the session when the user logs out or the session times out. Before the session expires, the session can continue to exist for a period of time, which is called the session timeout period. The servlet container will monitor the activity of the session and judge whether the session has expired according to the timeout period.
• Session data storage: The Servlet container provides a session data storage mechanism for storing session-related data. Memory-based storage saves session data in memory for quick access, but there is a greater risk of session loss. The session data is saved to an external storage medium (such as a database) based on a persistent storage method, making the session data more reliable. When a session ends or expires, the session data is deleted from the storage medium.
• Security processing: The Servlet container provides related security mechanisms to protect the security of the session. One of the common security measures is to use SSL/TLS protocol to encrypt session communication to prevent session hijacking and data leakage. The SSL/TLS protocol uses public and private keys to encrypt and decrypt communications to ensure the confidentiality and integrity of session data during transmission. In addition, you can also configure secure session cookie attributes, such as HttpOnly and Secure, to limit the access range of session cookies and enhance session security.

The main technical points of Servlet in Tomcat

In Tomcat, the technical principles of sessions mainly include the following aspects:

1. Session replication: Tomcat supports the session replication mechanism, that is, session data is replicated to multiple Tomcat instances to achieve load balancing and high availability. When a Tomcat instance receives a user's request, it first searches for session data based on the session ID. If the current Tomcat instance does not have the session data, it will send a request to other Tomcat instances to obtain the corresponding session data. It then copies the session data into its own memory and uses that data in subsequent requests.
2. Distributed session: Tomcat provides a distributed session management mechanism, which can store session data in an external shared storage (such as a database or cache server) to support session data sharing among multiple Tomcat instances. When a Tomcat instance receives a user's request, it saves the session data to shared storage and sends the session ID to the client. Other Tomcat instances can fetch session data from shared storage and identify and track a user's session based on the session ID.
3. Session persistence: Tomcat supports session data persistence to disk or database to ensure persistent storage of session data. When the session ends or expires, Tomcat will save the session data to disk or database. After application restart or container restart, Tomcat can restore session data from disk or database.
4. Session invalidation listener: Tomcat provides a session invalidation listener (Session Lifecycle Listener), which can monitor session creation, destruction, and invalidation events, and perform corresponding logical operations. By implementing the listener interface, developers can insert custom logic at key points in the session life cycle, such as logging, cleaning up resources, sending notifications, etc.
5. Security enhancement: Tomcat provides various security mechanisms to enhance session security. One of the common security measures is to enable SSL/TLS protocol to encrypt session communication. By configuring Tomcat's SSL/TLS connection, session data can be encrypted and decrypted using public and private keys. In addition, you can also configure secure session cookie attributes, such as marking session cookies as HttpOnly and Secure, to limit the scope of use of cookies and avoid the risk of XSS attacks and session hijacking.

Cookie configuration security attributes

• HttpOnly attribute: Setting the HttpOnly attribute of the session cookie to true prevents access to the cookie through JavaScript scripts. This can effectively prevent cross-site scripting attacks (XSS), because attackers cannot obtain user session cookie information through JavaScript. Make sure you set the HttpOnly attribute to true when setting the session cookie.
• Secure attribute: Setting the Secure attribute of a session cookie to true ensures that the cookie can only be transmitted over an HTTPS connection. This means that session cookies can only be transmitted over a secure connection encrypted with SSL/TLS, providing greater data transmission security. Make sure to set the Secure property to true in environments that only use HTTPS connections.

for example

Session management in servlet is an important technology in servlet, which is used to track the user's state. Here are some overviews and code samples on session timeouts, session tracking, and security.

Session Timeout (Session Timeout)

The session timeout defines how long the server waits after receiving the last request from the client before closing the session. This is what we web.xmlset in . Here's a code example that sets a timeout of 30 minutes:

<session-config>
    <session-timeout>30</session-timeout>
</session-config>

Alternatively, we can also dynamically set the session timeout in the servlet:

HttpSession session = request.getSession();
session.setMaxInactiveInterval(30*60); // in seconds

Session Tracking

Session tracking is a technique for maintaining session state. There are various ways to do this, such as using Cookies, URL rewriting or HttpSession.

1. Cookies

The server sets the cookie and passes it to the client. When the client makes the next request, it will bring this cookie, so the server can know which user is performing the operation. Here is an example of a simple servlet using cookies for session tracking:

import javax.servlet.http.Cookie;

public class CookieExample extends HttpServlet {
    
    
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    
    
        Cookie cookie = new Cookie("user", "John Doe");
        response.addCookie(cookie);
        // ...
    }
}

2. URL rewriting

URL rewriting is to append session information directly at the end of the URL path, such as:

String url = response.encodeRedirectURL("http://localhost:8080");
response.sendRedirect(url);

3. HttpSession

HttpSession is also a commonly used session tracking technology. Here is an example of a simple servlet using HttpSession for session tracking:

public class SessionExample extends HttpServlet {
    
    
    public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    
    
        HttpSession session = request.getSession();
        session.setAttribute("user", "John Doe");
        // ...
    }
}

safety:

We can configure access control using the element web.xmlin the file <security-constraint>to protect the servlet. For example, the following code configures that only users with the "admin" role can access resources under "/admin/*":

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Admin Area</web-resource-name>
        <url-pattern>/admin/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <role-name>admin</role-name>
    </auth-constraint>
</security-constraint>

For more knowledge on session management in servlets, please refer to the relevant tutorial or documentation.

On the other hand

In the far distant future, where advanced technology and artificial intelligence have become ubiquitous, a new breed of digital entities called “Servlets” emerged. These intelligent beings were designed to seamlessly integrate with the vast interconnected network known as the “Internet”.

Servlets were designed with the core principle of modularity and flexibility in mind. They featured a modular architecture that allowed them to handle diverse tasks, adapting to countless scenarios. Just like the characters in a science fiction novel, each Servlet possessed a unique set of skills and capabilities, enabling them to fulfill specific roles within the digital ecosystem.

Imagine a Servlet as a character equipped with a powerful set of tools and attributes. They had the ability to receive and process requests from clients, just like a protagonist would receive a mission in a thrilling adventure. These requests varied from simple data retrieval to complex computations, mimicking the challenges faced by protagonists as they navigated their futuristic worlds.

Servlets were designed to be highly adaptable, just like protagonists overcoming obstacles and evolving throughout their journeys. They were capable of modifying their behavior based on specific circumstances and needs, dynamically adjusting their responses to different client requests. This flexibility and versatility made them valuable assets in the ever-evolving digital landscape, just like protagonists who can adapt to any situation thrown their way.

Much like the interconnected nature of characters and plots in science fiction novels, Servlets formed a network of interactions within the Internet. They communicated with other Servlets, databases, and external systems, sharing and exchanging information. These interactions enabled Servlets to make collaborative decisions, leading to greater efficiency and effectiveness in accomplishing their tasks, just as characters team up to achieve their common goals.

In this science fiction-esque world, Servlets were not confined to a single physical location; they could exist and operate across multiple servers and platforms. This distributed nature provided resilience and scalability, allowing multiple instances of Servlets to handle high volumes of requests simultaneously, much like the parallel universes that protagonists traverse in their adventures.

In essence, the design of Servlets embodied the spirit of a science fiction novel, enabling them to seamlessly navigate the digital realm, adapt to various scenarios, collaborate with other entities, and operate across different platforms. Just as science fiction novels challenge our imagination and push the boundaries of what is possible, Servlets revolutionized web application development, redefining the way we interact with the Internet.