Hi,
On Wed, Nov 26, 2014 at 10:14 PM, Stuart Douglas <sdouglas_at_redhat.com> wrote:
> I don't really see what this would achieve, IMHO this situation is
> basically user error.
I also don't really see much benefit in a setting specifically for
authentication purposes.
What I do think has a great value is having some control over sessions
being created at all. There is currently the well known setting
available to control the time out of sessions, where a 0 or less means
infinite timeout and a 1 means 1 minute, etc.
Why not have some finer control there? Something to link the session
timeout to the duration of a single request and another setting to
forbid creating sessions completely would be great.
In well over 10 years over Java EE development I've seen people
implementing their own mechanisms for this over and over again. Often
by wrapping the HttpServletRequest, using server proprietary
mechanisms (like e.g. a Valve in Tomcat), and/or having a front-end
web server like Apache removing JSESSIONID cookies (which incidentally
could make the session problem worse, but I've seen people doing that
out of desperation).
A central switch that switches off sessions would also be really
convenient for various others specs. In JSF we could probably use that
switch to go to stateless mode (or alternatively saving state on the
client). Compatible JASPIC auth modules could use this switch to save
their required state in a cookie, etc.
Kind regards,
Arjan Tijms
>
> If you are using an authentication mechanism that requires a session
> then forcibly disabling the creation of sessions will just result in
> authentication being broken.
>
> If a user really does not want a session to be created it is up to
> them to pick an authentication mechanism that does not require one (and
> if the container they are using creates a session when it is not really
> required then I think this is just a container bug/feature and should be
> treated as such).
>
>
> Stuart
>
>>
>> Mark
>>
>>