-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jon,
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-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-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/catal
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
/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/catal
ina
/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.
---------------------------------------------------------------------
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/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5EGYMACgkQHPApP6U8
pFgewxAAimutw1exjBFgtBUUvj4I05KUH/Sy8G4TSXcUuYJv0pVGv2oztzNXp/Cz
IcJdj/mSDdg2c4TdLdsk9F2PCPOJdevmygJQbArcsgZd/X+RG8ZwPrZVJ26DweOJ
vrB8RsP/VDiXU4JJKjxN1SyIIWB9NRXpvGwUWsb8WTQosQFk94rq4N8XIQ2CGx8F
CgHu27Rn9/gTZv5tWscWKXK9mWfUsLoWJIbHz+ApfT4bKTop84trf4U2A5ug1jdF
c6eRZU2p9+TJuThOU0Mbt2akN9c7hYIYo6KZ8kpXV+zh1NteGlYYsDXKGP6lQsDL
5p5jvMVnKNPY00sz79XYhaqpU58kSSWGSy15AB1bMMmqQ9vs5QUKLJhJy8ZkMID6
5C/lDZe3hTlIn/E7NZyvBC27XVTh5ofUUviRUvNoMVPjPAw7QpNIzhtIrjgviBjp
uV7N1eEIA7jUGaVsH7a1/N+RxwCMqr31bfrr/kCTq9iBB2gvYAQXxAVTlkdj2bYQ
06ZmHpOAh1skqgLqMKIPI0p0EngN7XRYUCfu75AHgIcIqfYuc47DXqgeCKs5/sCk
iW+n9jpQ2r7/wgozPhO8Gnsve7ktjH3G58YBeBwUTB2hrVLDuCpuchmjPqJJaNfq
Fr7kAuGLqqBTUxnYpQiQPml8OzH2QSn0/z7yuRkm6ZfKsPpQSKM=
=ArT1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
