Recently I joined a new company and my project is a mobile payment system. Since it is related to money, the security requirements are particularly high. The project is divided into many subsystems. When deploying (testing), only one subsystem is placed on each Tomcat. For example, if there are 5 subsystems now, then 5 Tomcats will be started and placed on Linux. Why do this? Imagine if after going online, if one of the systems has a problem and the server needs to be restarted, if the five subsystems are put together, not all of them will be restarted! Now let's talk about the problem we encountered.
After the user logs in, there is a recharge connection in the management subsystem, and it will jump to the recharge subsystem to recharge. In this way, the jump across the JVM can only be jumped by redirect, but the user's own login status will be lost (login session is lost). Later, it was changed to forward to jump to your own jsp page, and then submitted to the recharge subsystem in the form to recharge. The session will not be lost during local development and testing, but Tomcat released to linux will be lost. Looking for various reasons, I thought it was a problem with the difference of the operating system.
Later, I found such a difference. The development test is a jump of two port numbers with different IPs, and the test released to linux is a jump of the same IP with different port numbers. This involves knowledge of browser sessions and cookies.
First of all, the session is stored in the container, and a session of a session will generate a jsessionid. When managing the session, it is searched according to the jsessionid. If it can be found, it will not create a new session. If it is not found, create a new session. OK This is a new conversation. Cookies are files stored on the client side. jsessionid will also be placed in cookies.
Two IPs and two ports will have two sessions and two cookies, so the session will be lost. First, a jsessionid will be generated for the first login in the management subsystem, and this session cannot be found in a cookie. A successful login session will be created. Then jump to the recharge subsystem, and a jsessionid will also be generated in the recharge subsystem. If you search for the session in another cookies, you can't find it, and a session will also be created. The previous session is lost like this.
One IP and two ports will have two sessions and one cookies, so the session will be lost. First, a jsessionid will be generated for the first login in the management subsystem, and this session cannot be found in cookies. A successful login session will be created. Then jump to the recharge subsystem, and a jsessionid will be generated in the recharge subsystem. If you go to the same cookies to find the session, you can't find it, and a session will be created to cover the previous session.
The solution is to prevent jsessionid from being automatically generated and put it in cookies. Instead, pass the jsessionid in the url without relying on cookies. In layman's terms, this is called url rewriting.
In this way, the first login to the management system will generate a jsessionid to create a login session. When I get to the recharge system, I will pass the jsessionid over there and a session will also be generated. It means that the two containers each generate their own session, but share the same jsessionid. In this way, every time you go to the container to fetch the session content, it will be fetched according to the same jsessionid, if it has been created. You can definitely get it in there. But the content inside is different. This session will not lose the old! ! !
There are many ways to make url rewrite, such as:
<c:url value=""/>
response.encodeRedirectUrl("");
response.encodeUrl("");
and many other methods. But to make the jsessionid in the cookies not used, the browser needs to completely disable cookies, etc. Another simple way is to configure it in Tomcat:
In tomcat_home/conf/context.xml, change <Context> to <Context cookies = "false"> and that's it! ! !
Then the url will automatically look like this:
http://127.0.0.1:8080/login.do;jsessionid=66B0A8E2B78940C7B1BB16ABB8E0D3E9?method=toLogin