So the manager would be this, I've noticed it uses the StandardSession, which explicitly prevents serialization of the user principal and auth type: org.redisson.tomcat.RedissonSessionManager
Two questions, on org.apache.catalina.Session, do the values getNote and setNote replicate across the cluster by default? I'm curious if we could solve this whole thing with a valve that copies the principal into the org.apache.catalina.Session or the HttpSession. Next, Chris are you saying RedissonSessionManager should use their own implementation of StandardSession that preserves the principal? I guess I never got the questions answered, why isn't this the default behavior? It seems tomcat goes well out of its way to *not serialize *the principal. I was wondering if there was a reason for that. Thanks! On Wed, Feb 12, 2020 at 10:07 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Carsten, > > On 2/12/20 10:54 AM, Klein, Carsten wrote: > > actually, Tomcat just does not serialize authentication > > information, that is AuthType (BASIC, DIGEST etc.) and the > > Principal, during session serialization. That affects session > > persistence across restarts (no> matter what manager is used) as > > well as session transfer between cluster nodes. > The DeltaManager does indeed handle this information. Both the > AuthType and the Principal. > > > As a result, persisted and reloaded sessions as well as sessions > > transferred between cluster nodes are no longer authenticated. > > I have to admit, I've never actually set up a Tomcat cluster (because > I think it's overkill for my purposes), but the code /is/ there. > > > I was pointing that out in this mailing list in late 2019 (Topic > > "Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o > > authentication related information"). > > > > To overcome this, I have a simple solution in mind. It's only about > > 10 new lines of code. Basically, it's a new boolean property > > 'persistAuthentication' for the manager. Mark Thomas agreed with > > optionally saving authentication information along with the > > persisted session (only, if the new option is true). He encouraged > > me to write an enhancement/patch and provide it as a Pull Request. > > > > The only problem for me is lack of time. Although the code itself > > is quite simple, the things making me holding back are the Git > > stuff, making Tomcat build in my Eclipse etc... > > Forget Eclipse. We can get you started very easily: > > $ git clone https://github.com/apache/tomcat > $ cd tomcat > $ ant deploy > > (done) > > - -chris > > > On 2/11/20 9:33 PM, Jonathan S. Fisher wrote: > >>>> Apologies, I'm not seeing how this helps, I don't see where > >>>> authentication information is transmitted > > > > No, seriously, what session manager are you using? > > > > -chris > > > >>>> On Tue, Feb 11, 2020 at 5:39 PM Christopher Schultz < > >>>> ch...@christopherschultz.net> wrote: > >>>> > >>>> 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-o > ut- > > > >>>>>>>> > dur > >>>> > >>>>>>>> > > i > >>>>>>> > >>>>>>>> > >>>> ng-session-failover-event-and-restarts > >>>>>>> <https://stackoverflow.com/questions/59833043/tomcat-logs-user-o > ut- > > > >>>>>>> > dur > >>>> > >>>>>>> > > ing-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/ca > tal > > > >>>>>>>> > ina > >>>> > >>>>>>>> > > / > >>>>>>> > >>>>>>>> > >>>> session/StandardSession.java#L1559 > >>>>>>> <https://github.com/apache/tomcat/blob/master/java/org/apache/ca > tal > > > >>>>>>> > ina > >>>> > >>>>>>> > > /session/StandardSession.java#L1559 > >>>> <https://github.com/apache/tomcat/blob/master/java/org/apache/catal > ina > > > >>>> > /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/ca > tal > > > >>>>>>> > ina > >>>> > >>>>>>> > > /session/StandardSession.java#L234 > >>>> <https://github.com/apache/tomcat/blob/master/java/org/apache/catal > ina > > > >>>> > /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. > >>>>> > >>>>> ------------------------------------------------------------------ > - --- > >>>>> > >>>>> > > > >>>>> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>>>> For additional commands, e-mail: > >>>>> users-h...@tomcat.apache.org > >>>>> > >>>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5EIqEACgkQHPApP6U8 > pFiEUQ//VSOyYvJeAh4aYLzq7nHwKCtBCMJBDJTdOdttCRBtztmvE1nK1BanBLz8 > CVSi0TLPkKjri/tnpnuOvPG7oUv19xG9J1Do7cWxw7mRg/lxk91Ce4oz9aENZIMn > 11DoW9TX5itWmmU4l0knGL1IXAKdFkxDPmd+hBAs934pPBeq5rPG/mZd0hQ1s4Qp > zeMnVBbX+uX6P2YW5wAGUS5Z4N6Y55BuD6olmV/dOKZ1FyKR76vPYErJ0Aj5tryl > G1/5aikwURTdLGFH2lOjaDoChueVrHckbZaaog8z0Vbnv/2eL5xml+AMVs60IYOg > da7gVF59WBAvGucpGKCsQn3BFerUgEw1pOPFa3NTT4BrgUvKQmGlGReUSvYASCgP > UAPmdtrUvudvnuxRPK8jO9uwLiniqwZ1OZttL+IREeGwKFkYJGphE1akI1XSSL7p > 9QKVfIt4wrSWwQke8CxmAjis8J9L1uJ88Uk6nV1cnzxoowdSidStKN3Jv3/prksk > cl2GqvcwGKXLt7g5q/DDhuyVpztB+1HpXO3eE7urTuX0lSEnxKuFCiNd4DDJfd5M > /EO7tFhtUkYuucGSS8dpN/uGZm61wYlpp2/he5zC7GkX/VKClJ4oNZ+OrEgtJDwU > v2ilAJS4czhUN/IrDywNh6Xk1+fdFmrCDtReTTblV19RVFo6vFY= > =qmsE > -----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.
