On 29/11/2019 11:48, Klein, Carsten wrote: <snip/>
> However, we are developing Ajax-driven > B2B client applications, which terminate / end the session when they > detect loss of authentication. Technically, these apps periodically send > keep-alive messages to the server (in order to keep the session alive, > since with Ajax the server is only queried when data must be loaded or > updated). When such a keep-alive fails with a 401 code, the session has > gone and the application terminates (so, the Admin is able to > 'disconnect' clients by invalidating their session). Currently, this > happens for all active clients after reloading the context or restarting > Tomcat :-( > >>> That may be a security thing, but if, for example, passwords stored in >>> the GenericPrincipal instance are not serialized, I don't see a security >>> problem with persisting the session's principal. >> >> User names and passwords are generally viewed as more sensitive that the >> Principal object which is generally viewed as more sensitive than the >> session ID. >> >> Where users draw the line between what is acceptable and unacceptable is >> going to vary. > > I'm with you. And likely our setup is special in a way. However, I've > rarely seen that you have to re-enter credentials in a professional web > application like Google or Facebook, for example. Yes. But if those apps were running on Tomcat I doubt that a) they'd be running on a single instance and b) they'd be using Tomcat's in memory session management. > In some of our projects we use self-written replacements for Tomcat's > GenericPrincipal (ours is serializable, I know yours in version 8 or 8.5 > is too, but on Ubuntu 14.04 we're still on Tomcat 7), StandardSession > and StandardManager. However, it's some work to keep these classes up to > date for new versions of Tomcat. So my basic question was, couldn't > Tomcat do that for us? As an option, disabled by default I don't see why not. > I understand that different users have different requirements and for > some, persisting a Principal (likely including a password) on disk for > some seconds during a reload is really not acceptable. BTW, why ever do > you save passwords?? Good question. I suspect it might be related to single-sign-on but I'd need to do some svn archaeology to try and answer that more definitively. > So, the best solution to that would be to make this a configurable > option of the Manager, named 'persistPrincipal', for example. Maybe I > could even help developing that (if I had some time). Agreed. A good place to start would be to open a Bugzilla enhancement request against 9.0.x (we always develop for the latest version first and then back-port). After that, we accept patches in Bugzilla or Pull Requests at GitHub. Expect a fair amount a feedback on your first version (my first patch needed to be completely re-written) but a couple of tips to reduce the rework: - enable checkstyle and make sure there are no errors when building - generally, follow the style of the code you are editing (the Tomcat code style is not always consistent) Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org