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.
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.
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.
Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
