Apologies, I'm not seeing how this helps, I don't see where authentication information is transmitted
On Tue, Feb 11, 2020 at 5:39 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----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 > <https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-during-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/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 > <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 > > -- Jonathan | 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.