-----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
