Home > Back-end >  Shiro, web project, a new Session ID is why every request?
Shiro, web project, a new Session ID is why every request?

Time:09-19

In the web project (the most common Servlet& JSP) used in shiro, only to find every request Servlet, get the session id by shiro is new (don't), don't know why?
Built a common Java Web project, custom Reaml, write a Servlet that each request the Servlet, print the subject Session ID, but each time get a different Session ID? Why is that? Where the code to write wrong? The code is as follows:

Shiro. Ini
 
[users]
Zhang=123, admin
[roles]
The admin=user: *


Custom realm
 
Public class MyRealm extends AuthorizingRealm {
@ Override
Protected AuthenticationInfo doGetAuthenticationInfo (AuthenticationToken token) throws AuthenticationException {
//regardless of certification
Return new SimpleAuthenticationInfo (" zhang ", "123", enclosing getName ());
}

@ Override
Protected AuthorizationInfo doGetAuthorizationInfo PrincipalCollection (principals) {
//regardless of authorization
SimpleAuthorizationInfo authorizationInfo=new SimpleAuthorizationInfo ();
Return authorizationInfo;
}
}


Context starts, to create the SecurityManager
 
@ WebListener
Public class MyServletContextListener implements the ServletContextListener {

Public void contextDestroyed (ServletContextEvent arg0) {
System. The out. Println (" destroyed ");
}

Public void contextInitialized (ServletContextEvent arg0) {
System. The out. Println (" initialized ");

//cookies
SimpleCookie sessionIdCookie=new SimpleCookie ();
SessionIdCookie. Elegantly-named setName (" sid ");

//our SessionManager
DefaultWebSessionManager our sessionManager=new DefaultWebSessionManager ();

Our sessionManager. SetSessionIdCookieEnabled (true);
Our sessionManager. SetSessionIdCookie (sessionIdCookie);

//SecurityManager
DefaultWebSecurityManager securityManager=new DefaultWebSecurityManager ();
SecurityManager. SetSessionManager (our sessionManager);
SecurityManager. SetRealm (new MyRealm ());

The SecurityUtils. SetSecurityManager (securityManager);
}
}


The Servlet
 
@ WebServlet (name="myServlet," urlPatterns="/login")
Public class MyServlet extends the HttpServlet {
private static final long serialVersionUID=1L;
@ Override
Protected void doGet (it the req, HttpServletResponse resp)
Throws ServletException, IOException {
Subject subject=SecurityUtils.getSubject();
System. The out. Println (" Session ID: "+ subject. GetSession (). The getId (), toString ());
}
}


In the browser input: localhost: 8080/test/login, enter, refresh again 2 times, the console output of the three different Session ID? Why is this?

The Session ID: b9e3faa1 - d4-4 b9d 55-8276-50 e717f179c0
The Session ID: 21 e14dff - 1079-403 - d - bde9edbc70 bc9b - 76
The Session ID: 90728816-9 ead f3c pilots - 4-8 aee - db2644635fa9

CodePudding user response:

The output of the SESSION timeout see you request. GetSession (). GetMaxInactiveInterval ()

CodePudding user response:

The elder brothers, it took me a long time and research study, by reading the source code, I found that the local session, which is not a web, it will not pass the jsessionid cookie to judge whether the login status, found by looking at the source code, is by the current thread binding with the subject, whether to implement the subject has logged in, because we are using the tomcat web server, use the connection pool, when the request to come over, there will be a thread to the corresponding response, each request of the corresponding thread is not the same, because the subject with the thread binding, or thread without subject, will log in again, and generate the session, so sessionid is different, but the connection pool is recycled, when we request for many times, you will find that the sessionid have repeat, the reason is that the thread before the subject has the login,
Hope can understand!

CodePudding user response:

refer to the second floor qq_42673099 response:
the elder brothers, it took me a long time and research study, by reading the source code, I found that the local session, which is not of the web, it will not pass the jsessionid cookie to judge whether the login status, found by looking at the source code, is by the current thread binding with the subject, whether to implement the subject has logged in, because we are using the tomcat web server, use the connection pool, when the request to come over, there will be a thread to the corresponding response, each request of the corresponding thread is not the same, because the subject with the thread binding, or thread without subject, will log in again, and generate the session, so sessionid is different, but the connection pool is recycled, when we request for many times, you will find that the sessionid have repeat, the reason is that the thread before the subject has the login,
Hope can understand!


Is there any related blog to introduce this problem? Finally how to solve the problem of

CodePudding user response:

Assess the program, don't repeat submitted

CodePudding user response:

Just ask a question, but also be delete,
I also met your problem, could you tell me how to solve the original poster is?

CodePudding user response:

refer to the second floor qq_42673099 response:
the elder brothers, it took me a long time and research study, by reading the source code, I found that the local session, which is not of the web, it will not pass the jsessionid cookie to judge whether the login status, found by looking at the source code, is by the current thread binding with the subject, whether to implement the subject has logged in, because we are using the tomcat web server, use the connection pool, when the request to come over, there will be a thread to the corresponding response, each request of the corresponding thread is not the same, because the subject with the thread binding, or thread without subject, will log in again, and generate the session, so sessionid is different, but the connection pool is recycled, when we request for many times, you will find that the sessionid have repeat, the reason is that the thread before the subject has the login,
Hope can understand!
do you this is not nonsense, sessionid is not the web, but also be read in two ways by default sessionid 1, read the JSESSIONID cookie
2, read the JSESSIONID url, the principle and the servlet session is not the same as you, repeat generated sessionId client did not send the sessionId certainly is!

CodePudding user response:

The same problem, the client did not send the session, but I have used the withCredentials: true