-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Jon,
On 2/11/20 5:36 PM, Jonathan S. Fisher wrote: >> What do you mean by logged out If it's one from Redisson, then >> you should look at their code and not > Tomcat's code. > > So you have two tomcat nodes: A & B, clustered in any fashion > (forget I mentioned redisson) of your choosing; let's say they're > clustered using the built in tcp point-to-point replication. The choice of session manager is ... pretty critical, here. So which session manager are you using/ > Have 5 people logged into an application on the first server using > standard JavaEE APIs (HttpServletrequest.login) Now turn off > server A. Your load balancer starts sending traffic to server B. > Their sessions will be there, BUT they will be logged out; one has > to call HttpServletRequest.login() again. Upon login, Tomcat > destroys the previous session (as it should), nullifying any > benefit for clustering the application in the first place. Tomcat does not destroy sessions when authenticating. > In the two links I provided, the StandardSession object goes to > great length to ensure that the security principal is not > serialized into the session True. > and therefore [not] replicated in the cluster. False. > Why is that? Why not serialize the security credential so the user > can bounce between servers? Authentication information is transmitted in a different way. I would really encourage you to look at the code for DeltaManager, which is the session manager typically used for clustering in Tomcat. If you are not using the DeltaManager, then you need to look at the code being used for your actual SessionManager. - -chris > On Tue, Feb 11, 2020 at 4:27 PM Christopher Schultz > <ch...@christopherschultz.net > <mailto:ch...@christopherschultz.net>> wrote: > > Jon, > > On 2/11/20 2:35 PM, exabrial wrote: >> https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-dur i > >> ng-session-failover-event-and-restarts > <https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-dur ing-session-failover-event-and-restarts> > > > > > > We've implemented session replication using Redisson, but we > noticed >> that if we intentionally fail a node, the user's sessions do get >> replicated, but they're logged out when they're restored on the >> new server. > > What exactly do you mean when you say "logged-out"? > >> Is there a way to make this work properly so the user doesn't >> get logged out during a failover event? > >> Most /More importantly, is there a technical or security reason >> for this? > > FYI the servlet specification does not guarantee that > <distributable> web applications also transfer authentication > information. > >> If you look at the Tomcat code, they actively try and avoid >> serialization the Security Principal: > >> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina / > >> session/StandardSession.java#L1559 > <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina /session/StandardSession.java#L1559> > > > > https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/ se > > ssion/StandardSession.java#L234 > <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina /session/StandardSession.java#L234> > > That code is for serializing the whole session, not transmitting > session information between cluster nodes. You need to read the > code for the various ClusterManagers and (more importantly), the > DeltaSession class. > > Which SessionManager are you using? If it's one from Redisson, > then you should look at their code and not Tomcat's code. > > -chris > > > > -- Jonathan | exabr...@gmail.com <mailto:exabr...@gmail.com> > Pessimists, see a jar as half empty. Optimists, in contrast, see it > as half full. Engineers, of course, understand the glass is twice > as big as it needs to be. -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5DOyEACgkQHPApP6U8 pFg1Pg//SXlXbzvMMRJ281amJdiwZ+k9n5GJYBzXBUlmk6KnPY9yw1hovw1/Bshb N/5qyjlcyCAtYCcuexJlvk06APgWPAgLtrXdg+mLW1yca7ic/OGcAnWi7u2ULSz3 dBjWucWDwNLPI27zs0wfDwCh9F+Bx5tOzShKaSNeghevazABFsAd7HQOEIoauv1t Ccq0DxuBHufiZn4vXwCPeFSaeQI/OGOUj1WenJWo6CSGM/Qlr8bf5n0uHYqV9ltx uz9SXEYerqpvQxQYeGsdMQ87U8hItucgNYwcqf+VC1Ky4YllcaaAsWNxKx8ULEcQ 7uNJx3Okth/+/Dq9ZA0wb8aT0joAOq16cJZgZQKMmqaSdc9gY14YD9dM00QeyNSD OXxPGcM093/ShNFHiilOhk9x5AjwIxHHCxI2Lt4p8NvZyzlRSOTr+XSCBauHmS4H JY6vJGPhbgcmmFt5k3EIoSZs1jEKOjqyK7sEVqcsl1cWedLml/rJwnupEzIC6WF2 QLo+zNL/Bu3rVAu1xde7cdIPZf1zVX7grURdLCl1DXEyrXrjzj6b1YZr5IDsNVGX nygTk8mpB5oEWjX6oNMXFBGCjVO2xC843oRgXBDt0ql8pHQ1T8crP5IAzEAcgJm/ uBVaFVOvWG0g6CrK4B+rZQxxjbm0Tczw9DrzoAyb1Vd0X/gc1nE= =5Xd8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
