Hi,
> Not necessarily. Just had a case two weeks back were an auth context (concept in JASPIC that manages a stack of modules) stored the currently chosen stack in the session, but there was only one stack. If it saves this to a temporary session nothing would break.
By saving in session I guess you mean HttpSession#setAttribute().
Then what is the difference between HttpServletRequest#setAttribute() and the imaginery temporary session ?
If I want to keep my app sessionless then I'd use HttpSessionListener that throws an exception as soon as a session is created. Not just log it.This will tell me immediately that I'm taking a wrong path or I'm using not optimal (for my use case!) web container/framework/extension.
By adding a new setting that tells what should be the behavior you'd force every container/framework/extension to support both states.Why a framework that relies on sessions should be against the spec, assuming the new setiing says "stalessless only", and another framework that is completely stateless by design should care about "stateful" mode ?
My 2c.
Cheers
On Friday, 28 November 2014, 12:58, arjan tijms <arjan.tijms_at_gmail.com> wrote:
Hi,
On Friday, November 28, 2014, Stuart Douglas <stuart.w.douglas_at_gmail.com> wrote:
* It's not as user friendly and obvious for new users
Does this really matter? I don't think this is a really common use case.
I haven't really surveyed this topic, but from personal experience I know that I've seen it in pretty much every Java EE application I've been involved with. The concept of stateless (almost always meaning no-sessions) comes up really often in discussion about web frameworks. And the question really did came up more than once on SO.
* HttpSessionListener is great for logging the stack, but can't
replace or veto the session about to be created
* Wrapping HttpServletRequest in a filter can replace the session, but
sessions can be created before the first filter hits, e.g. by a
(JASPIC) auth module.
If you have an auth module that requires a session then is seems likely that disabling sessions will break your authentication, replacing one problem with another.
Not necessarily. Just had a case two weeks back were an auth context (concept in JASPIC that manages a stack of modules) stored the currently chosen stack in the session, but there was only one stack. If it saves this to a temporary session nothing would break.
Another example is that modules could use the global switch to save their state in a cookie instead, of if they can't/won't do this, throw an exception so that it's clear the module in question isn't compatible with session/stateless operation.
One step further, with such a switch in place a next version of the JASPIC spec (or the Security API) could even let modules declare this explicitly, and then the container can check this during startup. Basically like CDI is doing now with Passivating scopes and checking whether a bean is serializable.
For the 3rd party library case (e.g. the JSF case you mentioned) this approach will work fine.
* From a user wrapping the HttpServletRequest other specs can't infer
the user's intention; in JSF we can't process this to switch to save
state on client.
If a user wants client side state saving they can just explicitly specify it.
They can, and then also set a similar setting for MVC (hope they will have one), and then check all auth modules used and set settings on them too, and then check additional (web) libraries to see if they have their own settings for this, and then try to prevent JSP pages from creating a session in a custom way, etc.
It's not that it all can't be done today, but having a clear declaration stating that the app doesn't want sessions with one switch sure would make things simpler and would open up a range of new possibilities for automatic validation of deployments.
Kind regards,
Arjan
I am -1 on this at the moment, it seems like a niece use case that there are already ways to solve.
Stuart
> I guess I am -0 on this at the moment.
I'm personally +1 on the switch, but could also see a somewhat lower
level facility where an HttpSessionListener (or other listener) has
the ability to provide a replacement HttpSession (or null even). That
could pretty much also solve the first 3 points listed above.
Kind regards,
Arjan
>
> Mark
>