Whenever anyone "authenticates" with Seraph they get a HttpSession. This has a cost because Tomcat must keep a HttpSession object around for say 4 hours. JAC was recently found to have 70MB of HttpSession objects in it (Bots where the main problem but still).

I propose that we change Seraph so that it no longer creates a session when it detects that the auth mechanism is BASIC AUTH

This would save on sessions for "Out Of Browser" REST calls such as curl et al..

So why is there a session really?
Seraph uses DefaultAuthenticator.LOGGED_IN_KEY in the session to know that a user has logged in on future requests. This is really there for the browser experience. Eg one login and then sessions of interaction.

Really old bits of JIRA code used to look for req.getSession().getAttribute(DefaultAuthenticator.LOGGED_IN_KEY) to get the current user instead of using the other Seraph AuthContext.getUser() mechanism.

These have been removed fro all intents and purposes in 4.4.4 I think. (Its complicated but its never read only set...kinda...sorta...trust me)

If no session was created on BASIC AUTH calls then nothing in JIRA would break, I also doubt whether any other apps are using LOGGED_IN_KEY to get the current user in code.

The purpose of this page is to find out of any other Seraph users reply on DefaultAuthenticator.LOGGED_IN_KEY being in a session DURING a BASIC AUTH call?

When to do this?
In the next major version of Seraph to get out in the version of the products choosing