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. That's not how things should 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 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 > >
