Done, I checked the respective Request (implementation of HttpServletRequest) of Tomcat and Jetty, and both set the session id through a setRequestedSessionId(String). If I use reflection to obtain and call this method, set the sessionId before getSession. After the experiment works on Jetty, I will try Tomcat again. These two containers are what I commonly use, and I will check them out when I encounter other containers.

The code is simple:

    try {
        request.getClass ()
             .getMethod("setRequestedSessionId", String.class)
             .invoke   (request , id);
    } catch ( NoSuchMethodException ex) {
        // Log
    } catch (IllegalAccessException |
           IllegalArgumentException |
          InvocationTargetException ex) {
        // Log
    }

Haha!

It should be noted that it must be executed before the current request calls getSession for the first time. Pay special attention to whether there is a Filter in the upper layer that uses Session

2016/05/21 Updated experimental results

The SessionID can be replaced in the above method, but the Session cannot be taken out, because the Session will be verified when taking it out, and the source code of Jetty will be tracked to find out that the Session object is set when the Request is initialized, as shown below:

At this time, I haven’t progressed to Servlet and Filter yet, so I can’t start, so it seems that resetting is not that simple.

The above was only tested on Jetty, and the result failed. There is no experiment on Tomcat. If you look at the source code, there is a changeSessionId(String) method. It should be possible based on the logic.

Results updated again on 2016/05/21

After constant tossing, the sessionId was successfully reset using the following code:

    try {
        Object obj;
        obj = req.getClass ()
           .getMethod("getSessionManager")
           .invoke   (req);
        obj = obj.getClass ()
           .getMethod("getHttpSession" , String.class)
           .invoke   (obj, sid);
        req.getClass ()
           .getMethod("setSession", HttpSession.class)
           .invoke   (req, (HttpSession) obj);
    } catch ( NoSuchMethodException ex ) {
        // Log
    } catch (IllegalAccessException  |
           IllegalArgumentException  |
          InvocationTargetException ex ) {
        // Log
    }

Nothing needs to be changed in the program executed after this. You can use request.getSession() to read and write the Session normally. This method is written for Jetty.

2015/05/22 Tomcat actual measurement update

I was bored after breakfast, so I tracked the Tomcat code, using Tomcat 7 and 8 versions, and found that the Request object handed to the user Servlet is a proxy class called RequestFacade, which only implements the methods of the HttpServletRequest interface. , hiding his Request object, so methods such as setRequestedSessionId of org.apache.catalina.connector.Request cannot be called.

It seems that this Hack can only be implemented for Jetty.

Although the results are not optimistic, and Jetty may hide those methods in future versions, this experimental process has given us a better understanding of these two application containers. Whether it's Cookie, URL Path Parameter, or GET/POST parameters, they just carry Session Token in different locations of the request data. It may be more convenient to simply encapsulate the connection on the client side.

Use token and put the token in the request header. The front-end is required to bring this token when making requests