On 29/11/2019 11:48, Klein, Carsten wrote:


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


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

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


To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to