How to understand SessionId?
Anyone who has logged in to a website will encounter such a situation: after logging in to a website, as long as the browser is kept open, even if the pages related to the website are closed, the website will still be logged in again. condition. On the contrary, close the browser, and the next time you visit the website, it will be offline. For example, I visited the websites of Kugou and CSDN, and wrote while listening to songs. For some reason, I closed the CSDN website. When I visit CSDN again, I can find that I am still logged in. But if I close the browser, I need to log in before I can continue to write. Of course, some websites have developed functions such as automatic login.
Web pages are parsed based on the Http protocol, which is a stateless protocol. The so-called stateless is that the next visit does not know the situation of the previous visit, and the connection is disconnected after each visit. So, how does the server identify the user who is accessing it? Session and cookies are used here. Anyone who knows Session and Cookie will know that Session is saved on the server side, and Cookie is saved on the client side. So, how does the server session identify the user?
In this regard, I created a new project and set up an interceptor to identify whether the user is already logged in. After logging in, you can access the test page, and if you are not logged in, you can jump to the login page.
Each time the program is initialized, the client can see that there is a SessionId by viewing the value of the Cookie. That is, when the program is initialized, the server returns the SessionId to the client through Response, and the client stores it in a Cookie. Next, every time you visit the website, you will visit with this SessionId. The background can know the user's status according to the SessionId. Once the browser is closed, the changed cookie will be cleared by default. The problem seems to be solved here, but after restarting the server several times, it is found that the SessionId returned by the Response is the same each time it is initialized, so there is no uniqueness. The absence of uniqueness means that it cannot be used as an identification.
So I continued to look down and found that in tomcat, the Session is stored in the org.apache.cataline.session.ManagerBase class in the format of HashMap, that is, stored in the format of key-value, the key is sessionId, and the value is org . .apache.cataline.session this interface. At this point, we can find that the SessionId returned by the program initialization to the client is actually a key. Through this key, we can find the org.apache.cataline.session interface, which is implemented by the org.apache.cataline.session.StandardSession class. , At the same time, this class also implements HttpSession, and the data of HttpSession in tomcat is the data set with session.setAttribute(key, value).
At this point, it is basically possible to explain the situation in which the simulated scenario occurs. After the browser is closed, the SessionId is cleared instead of the Session. At this time, the Session still exists in the server. The SessionId brought to the background during the new access process is no longer the previous SessionId, and the user's identity cannot be identified if the previous corresponding value cannot be found. If the browser is not closed, the cookie that saves the SessionId value has not been deleted, excluding the possibility of manual modification. The new access brings the original SessionId to the background, and the server finds the Session value through the SessionId, so it maintains the original state.