On Tue, Feb 18, 2020 at 9:19 AM Carsten Klein <c.kl...@datagis.com> wrote:
Rémy,
Can you describe an actual use case for this ? Without clustering, I
don't
understand why the auth persistence is useful at all [when using
clustering, the delta manager persists that auth information]. To be
honest, that's also the case for session persistence itself, which does
not
provide a QoS level that is still relevant today. But the feature is
already there [maybe it could be considered for removal in 10 actually
...].
Why is session persistence across restarts not still relevant today?
Tomcat, as well as likely any other servlet container, stops/starts a
context when actually a reload (aka reconfigure) action would be
required (I guess, that's specified servlet specs, right?).
A context needs to be completely restarted for any configuration change
(oh, we need to add a new allowed host to the CORS filter, etc.).
Restarting, and so loosing all runtime data (the session), makes this
simple stop/start approach (from a programmer's point of view) difficult
to use in a production environment. I often find myself doing such
configuration changes in the evening in order not to drop logged on
users (that's when I'd better enjoy some freetime *g*).
That's why I believe, that session persistence across restarts is
required still today. Of course, there may be frameworks, including
clustering, that can do a lot for you. However, I'm talking about
Tomcat, not other frameworks. Why shouldn't Tomcat on its own provide a
production-system-ready "reconfigure" action? It did in the past, why
dropping it? That feature seems not too buggy...
Also, for me, setting up a Tomcat cluster with at least two machines,
only for getting session persistence during reconfiguring the nodes
seems a bit overdrawn. In our setups we typically have one server
machine, serving between 10 and 50 users at a time. I just can't tell my
customer to double the hardware just in order to keep users logged on
while we are working on the configuration.
Maybe you think it's "overdrawn", but right now you have very poor QoS.
What happens while the webapp/server is away ? Do you think the user will
not see anything bad ? [aka: please don't do anything until the restart is
done ...] Plus what happens if you have 10000s of sessions ? It gets slow
and some have complained about it in the past. Etc etc.
Rémy,
in our case, the app runs standalone in the browser and is fully AJAX
driven, so, if the server restarts in some 10 seconds, the user does not
even recognize. Maybe one or other request to the server (loading/saving
some data) is slow, since it waits for the server to be up again. In
very rare cases, it may run into a timeout, in which case the app comes
up with a message box "Server is currently not available, please try
again in some minutes."
BTW, session persistence can simply be disabled even today, by setting
StandardManager's pathname to en empty string.
Yes, with 10000s of sessions persistence may be a bottleneck (even with
PersistentManager). However, actually, we do not have so many sessions.
Maybe that is the general point. There are so many scenarios, Tomcat is
used in. So, who will actually really know, which features are good and
which are bad? It always depends on the actual scenario. Of course,
security is important and software vendors must ensure to publish secure
(-by-default) software. I agree, that saving the principal to disk for
some seconds may be a security risk for some apps and some people.
That's why the new feature is configurable and defaults to off.
However, as a server admin, I'm able to secure the installation that
way, so that nobody external is able to read such session files. Of
course, with the root password, you are always able to do lot of bad
things (includes attaching to the JVM and reading passwords directly
from memory). So, when security is an issue, NOT saving passwords at all
could be a first step :-p
That's not how things should happen today.
Whats your proposal? How should things happen today?
It may be the case, that today, many setups use WAR files, including
code and configuration, which are deployed at regular intervals or at
scheduled deploy times. However, that's not how we work. We like to be
able to react contemporary when a problem in a production system comes
up (our customers like that, too).
So, that's my plea for session persistence across restarts, as
implemented in recent versions. Nearly the same use case applies to
persisting authentication information as well.
The feature is there right now, so you're good ...
In our setups, we use the session mainly for authentication. The problem
that comes with not persisting authentication may not be obvious with
simple (browser driven) BASIC authentication, since the Browser sends
those Base64 encoded credentials with each request. Using session based
authentication (send credentials once and rely that your session remains
authenticated) is more modern and likely a bit more secure, right?
However, in that scenario, it's really bad, if your authentication has
gone after the context has been restarted. In that case, you may be
forwarded to the login page (when using FORM authentication). In our
case, our AJAX-style JavaScript client just logs you off and all your
work is gone (that's like if your browser crashes occasionally and has
no "restore previously opened tabs" feature...). In our case,
authentication information is the only valuable data in the session (we
don't save any attributes). So, isn't persisting authentication
information (for the sake of completeness) a feature of its own?
In other words, why not persisting authentication information? That data
is the only data, that currently is NOT persisted. Why not? Comments in
the code only mention, that authType and principal are transient. But
why? If there is a session persistence feature in Tomcat, shouldn't it
persist the session as a whole (at least, as much as possible)? Since
recent versions of Tomcat's default GenericPrincipal do no longer save
passwords, persisting authType and principal seems not being harmful to me.
Again, session persistence across restarts is just a "workaround" for
the missing "reconfigure" action. For me, it's the tribute for using the
much simpler stop/start schema in servlet containers (in contrast to a
real reconfigure action, which often tends to get quite complex).
Typically, persisted sessions do not remain on disk for a long time -
only while restarting.
Mark Thomas suggested to make that an optional feature, which is off by
default. That's what I've done. However, at that time it was not obvious
(at least to us) that passwords are no longer saved in GenericPrincipal.
With that in mind, I would even vote for making that new option
defaulting to true.
Indeed it leaks everything in clear text equivalent, including the user
passwords in it would be a giant red flag [the password removal only
occurred in the Tomcat 10 branch for compatibility reasons], but the rest
isn't so cool either. Again, that's not what things should happen today,
session persistence can only be considered a developer tool right now.
I'm curious about how to do things today in a better way. Many people
need something like session data and many people also like their
authentication not to be dropped after a while. I guess, these
requirements are still valid ones for today's web applications, right?
Carsten
I would be "ok" (lots of quotes) with this whole idea in Tomcat 10 if
persistence also becomes disabled by default, otherwise -1.
Rémy
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
