In-depth explanation of Session and Cookie in Tomcat

Preface

HTTP is a stateless communication protocol. Each request is independent of each other, and the server cannot identify previous requests. For Web applications, their activities are all dependent on a certain state, such as user login. At this time, using HTTP requires it to have the ability to provide logged-in information for subsequent requests after a login request. This article was first published on the public account Dunwu Source Code.

The solution is to use cookies, which are returned by the server to the browser, which caches and submits the cookie data to the server on each request. Cookies are transmitted in plain text in requests and are limited to 4KB in size. Obviously, it is unreliable to save all state data in the browser. The mainstream approach is:

1. When the browser makes the first request, the server assigns a unique identifier to the user, which is returned and stored in the browser's Cookies.
2. The server maintains a global request status library and uses a generated unique identifier to associate the status information of each request.
3. Subsequent requests from the browser will submit the unique identifier to the server in order to obtain status information of the previous request.

For ease of management, the server calls the entire process a session and abstracts it into a Session class, which is used to identify and store information or status about the user.
Next, we will analyze the source code implementation of Tomcat using version 6.0.53, through the parsing and generation of session identifiers, and the creation, destruction, and persistence of sessions.

1. Resolve the session identifier

Cookie is the most commonly used session tracking mechanism. All Servlet containers support it, including Tomcat. In Tomcat, the standard name of the cookie that stores the session identifier is JSESSIONID.

If your browser does not support cookies, you can also use the following method to record identifiers:

• URL rewriting: Included in the URL as a path parameter, such as /path;JSESSIONID=xxx
• URL request parameters: Add the session unique identifier as a query parameter to all links on the page, such as /path?JSESSIONID=xxx
• FORM hidden field: A hidden field is used in the form to store a unique value and is submitted to the server with the form

Tomcat implements the extraction of JSESSIONID from URL rewriting path and Cookie. Before analyzing the source code, first look at the key information of the header fields of the response to set cookies and the request with cookies:

// Set Cookie
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=56AE5B92C272EA4F5E0FBFEFE6936C91; Path=/examples
Date: Sun, 12 May 2019 01:40:35 GMT

// Submit Cookie
GET /examples/servlets/servlet/SessionExample HTTP/1.1
Host: localhost:8080
Cookie: JSESSIONID=56AE5B92C272EA4F5E0FBFEFE6936C91

1.1 Rewriting paths from URLs

A URL that includes a session ID path parameter is as follows:

http://localhost:8080/examples/SessionExample;JSESSIONID=1234;n=v/?x=x

Simply put, it is to find the JSESSIONID between the matching semicolon and the last slash, which is indeed the case, except that Tomcat operates on bytes. The core code is in the CoyoteAdapter.parsePathParameters() method, which is not posted here.

1.2 From the Cookie header

The method call that triggers Cookie parsing is as follows:

CoyoteAdapter.service(Request, Response)
└─CoyoteAdapter.postParseRequest(Request, Request, Response, Response)
 └─CoyoteAdapter.parseSessionCookiesId(Request, Request)
 └─Cookies.getCookieCount()
 └─Cookies.processCookies(MimeHeaders)
 └─Cookies.processCookieHeader(byte[], int, int)

This processCookieHeader operates on bytes, and parsing does not seem intuitive. There is also a method marked as deprecated in Tomcat that uses string parsing to help understand it. The code is as follows:

private void processCookieHeader(String cookieString){
 // Multiple cookie values ​​are separated by commas StringTokenizer tok = new StringTokenizer(cookieString, ";", false);
 while (tok.hasMoreTokens()) {
  String token = tok.nextToken();
  // Get the position of the equal sign int i = token.indexOf("=");
  if (i > -1) {
   // Get name and value and remove spaces String name = token.substring(0, i).trim();
   String value = token.substring(i+1, token.length()).trim();
   // RFC 2109 and bug remove double quotes at both ends"
   value = stripQuote( value );
   // Get a ServerCookie object from the internal cookie cache pool ServerCookie cookie = addCookie();
   // Set name and value
   cookie.getName().setString(name);
   cookie.getValue().setString(value);
  } else {
   // we have a bad cookie.... just let it go
  }
 }
}

After parsing, the next step is to traverse and try to match the cookie named JSESSIONID in the parseSessionCookiesId method. If it exists, its value is set to the requestedSessionId of the Request and associated with an internal Session object.

2. Generate session cookies

The cookies related to the session are generated by Tomcat itself. When Request.getSession() is used in the Servlet to obtain the session object, the execution is triggered. The core code is:

protected Session doGetSession(boolean create) {
 ...
 // Create a Session instance if (connector.getEmptySessionPath() && isRequestedSessionIdFromCookie()) {
  // If the session ID came from a cookie, reuse it, if it came from a URL, don't // reuse it to prevent possible phishing attacks session = manager.createSession(getRequestedSessionId());
 } else {
  session = manager.createSession(null);
 }
 // Create a new session cookie based on the Session
 if ((session != null) && (getContext() != null)
    && getContext().getCookies()) {
  String scName = context.getSessionCookieName();
  if (scName == null) {
   //Default JSESSIONID
   scName = Globals.SESSION_COOKIE_NAME;
  }
  // Create a new cookie
  Cookie cookie = new Cookie(scName, session.getIdInternal());
  // Set path domain secure
  configureSessionCookie(cookie);
  // Add to the response header field response.addSessionCookieInternal(cookie, context.getUseHttpOnly());
 }
 if (session != null) {
  session.access();
  return (session);
 } else {
  return (null);
 }
}

Added to the response header field, it is generated according to the Cookie object in the format described at the beginning.

3. Session

Session is an interface within Tomcat and a facade class of HttpSession, used to maintain state information between requests of specific users of a web application. The relevant class diagram design is as follows:

The functions of key classes or interfaces are as follows:

• Manager - manages the Session pool. Different implementations provide specific features, such as persistence and distribution.
• ManagerBase - implements some basic functions, such as Session pool, unique ID generation algorithm, and is easy to inherit and extend
• StandardManager - Standard implementation that provides simple session persistence across restarts of this component (for example, when the entire server is shut down and restarted, or when a specific web application is reloaded)
• PersistentManagerBase - provides a variety of different persistent storage management methods, such as files and databases
• Store - provides persistent storage and loading of session and user information
• ClusterManager - Cluster session management interface, responsible for session replication
• DeltaManager - incrementally replicates session data to all members in the cluster
• BackupManager - replicates data to only one backup node, visible to all members of the cluster

This article does not analyze the principles of cluster replication, but only analyzes the management of stand-alone sessions.

3.1 Create Session

When you first use Request.getSession() to get a session object in a Servlet, a StandardSession instance is created:

public Session createSession(String sessionId) {
 // The default return is new StandardSession(this) instance Session session = createEmptySession();
 // Initialize properties session.setNew(true);
 session.setValid(true);
 session.setCreationTime(System.currentTimeMillis());
 // Set the session validity period in seconds. The default value is 30 minutes. A negative value means it never expires. session.setMaxInactiveInterval(((Context) getContainer()).getSessionTimeout() * 60);
 if (sessionId == null) {
  // Generate a session ID
  sessionId = generateSessionId();
 
 session.setId(sessionId);
 sessionCounter++;

 SessionTiming timing = new SessionTiming(session.getCreationTime(), 0);
 synchronized (sessionCreationTiming) {
  sessionCreationTiming.add(timing);
  sessionCreationTiming.poll();
 }
 return (session);
}

The key lies in the generation of the session unique identifier. Let's look at Tomcat's generation algorithm:

1. Get 16 bytes randomly
2. Encrypt these bytes using MD5, again getting a 16-byte array
3. Traverse the new byte array and use the high and low 4 bits of each byte to generate a hexadecimal character
4. Finally, we get a 32-bit hexadecimal string.

The core code is as follows:

protected String generateSessionId() {
 byte random[] = new byte[16];
 String jvmRoute = getJvmRoute();
 String result = null;
 // Render the result as a string of hexadecimal numbers StringBuffer buffer = new StringBuffer();
 do {
  int resultLenBytes = 0;
  if (result != null) { // Repeat, regenerate buffer = new StringBuffer();
   duplicates++;
  }
  //sessionIdLength is 16
  while (resultLenBytes < this.sessionIdLength) {
   getRandomBytes(random); // Get 16 bytes randomly // Get the summary of these 16 bytes, using MD5 by default
   random = getDigest().digest(random);
   // Traverse this byte array and finally generate a 32-bit hexadecimal string for (int j = 0;
   j < random.length && resultLenBytes < this.sessionIdLength;
   j++) {
    // Generate a hexadecimal character using the high and low 4 bits of the specified byte byte b1 = (byte) ((random[j] & 0xf0) >> 4);
    byte b2 = (byte) (random[j] & 0x0f);
    // Convert to hexadecimal digits if (b1 < 10) {buffer.append((char) ('0' + b1));}
    // Convert hexadecimal characters to uppercase else {buffer.append((char) ('A' + (b1 - 10)));}
    
    if (b2 < 10) {buffer.append((char) ('0' + b2));}
    else {buffer.append((char) ('A' + (b2 - 10)));}
    resultLenBytes++;
   }
  }
  if (jvmRoute != null) {buffer.append('.').append(jvmRoute);}
  result = buffer.toString();
 } while (sessions.containsKey(result));
 return (result);
}

3.2 Session Expiration Check

One web application corresponds to one session manager, which means there is a Manager instance inside StandardContext. Each container component starts a background thread and periodically calls the backgroundProcess() method of itself and its internal components. The Manager background processing is to check whether the Session has expired.

The logic of the check is to get all sessions and use their isValid to determine whether they are expired. The code is as follows:

public boolean isValid() {
 ...
 // Whether to check whether it is active, the default is false
 if (ACTIVITY_CHECK && accessCount.get() > 0) {
  return true;
 }
 // Check if the time has expired if (maxInactiveInterval >= 0) { 
  long timeNow = System.currentTimeMillis();
  int timeIdle = (int) ((timeNow - thisAccessedTime) / 1000L);
  if (timeIdle >= maxInactiveInterval) {
   // If expired, perform some internal processing // Mainly notify listeners interested in expiration events
   expire(true);
  }
 } // Plural numbers never expire return (this.isValid);
}

3.3 Session Persistence

Persistence means serializing the active Session objects in memory into a file or storing them in a database. If the session management component complies and has persistence enabled, storage is performed in its lifecycle event stop method; loading is performed in the start method.

Persistence to file. StandardManager also provides the function of persistence to file. It will write all active sessions in the session pool to the CATALINA_HOME/work/Catalina/<host>/<webapp>/SESSIONS.ser file. The code is in its doUnload method.

FileStore also provides the function of persisting to files. The difference from StandardManager is that it writes each session to a single file named <id>.session.

Persist in the database and store session-related data in a table, including serialized binary data. The table field information is as follows:

create table tomcat_sessions (
 session_id varchar(100) not null primary key,
 valid_session char(1) not null, -- Validity max_inactive int not null, -- Maximum validity time last_access bigint not null, -- Last access time app_name varchar(255), -- Application name, in the format of /Engine/Host/Context
 session_data mediumblob, -- binary data KEY kapp_name (app_name)
);

Note: You need to put the database driver jar file in the $CATALINA_HOME/lib directory to make it visible to the class loader inside Tomcat.

4. Summary

This article briefly analyzes Tomcat's management of Session. Of course, it ignores many details. Those who are interested can go deep into the source code. The implementation of Tomcat cluster Session will be analyzed later.

Summarize

The above is the full content of this article. I hope that the content of this article will have certain reference learning value for your study or work. Thank you for your support of 123WORDPRESS.COM.