On 08/12/2014 22:10, Edward Burns wrote:
>>>>>> On Wed, 26 Nov 2014 06:39:49 +0000, Yannick Majoros <yannick.majoros_at_gmail.com> said:
>
> YM> Hello,
> YM> A couple of weeks ago, I wrote this message in the Java EE users mailing
> YM> list. Bill Shannon suggested that it would be interesting to post it here.
>
> It sure was interesting! Lots of folks coming out of the woodwork on
> this one.
>
> Yannick Majoros "[servlet-spec users] session(-less) applications"
> Mark Thomas "[servlet-spec users] Re: session(-less) applications"
> Stuart Douglas "[servlet-spec users] Re: session(-less) applications"
> arjan tijms "[servlet-spec users] Re: session(-less) applications"
> Greg Wilkins "[servlet-spec users] Re: session(-less) applications"
> Martin Grigorov "[servlet-spec users] Re: session(-less) applications"
> Remy Maucherat "[servlet-spec users] Re: session(-less) applications"
> Mark Struberg "[servlet-spec users] Re: session(-less) applications"
>
> I hate to have had all this excellent discussion and end up doing
> nothing, though sometimes that is indeed the right decision. Let's
> entertain Mark Thomas's suggestions:
>
>>>>>> On Wed, 26 Nov 2014 12:17:58 +0000, Mark Thomas <markt_at_apache.org> said:
>
> MT> I think it makes sense for some wording to be added to section 13.6 of
> MT> the Servlet spec to:
> MT> - make clearer which authentication mechanisms (FORM) are expected to
> MT> create HTTP sessions (I assume everyone is creating HTTP sessions
> MT> to handle FORM auth)
>
> Section 13.6.3.1 currently does say:
>
> Spec> Form based login should only be used when sessions are being
> Spec> maintained by cookies or by SSL session information.
>
> Need we say more?
Insert the following at the start of 13.6.3.1:
"Form based authentication requires that an HTTP session is available."
While this is implied from 13.6.3.1 I don't see any harm in being explicit.
> MT> - highlight the pros/cons of creating sessions rather than
> MT> authenticating on every request
>
> Can someone suggest some text for this purpose? I've listed this as an
> Adopt-a-JSR task for JSR-369: <https://jcp.org/en/egc/view?id=369>. We
> could also include Greg's idea about using an HttpSessionListener to aid
> in this sort of work.
13.6.6 Implementation considerations
Authentication can be a relatively expensive operation. To mitigate
this, containers may wish to cache the authentication result in the HTTP
session if one exists. Containers may wish to go further and create an
HTTP session to cache the authentication result if an HTTP session does
not exist. Automatically creating a session may create issues for
applications that have been implemented in a stateless manner. If a
container creates a session purely to cache authentication results that
the container [should | is strongly encouraged to | must] provide an
option to disable this behaviour per application.
>
> MT> - recommend that containers that create sessions purely to cache the
> MT> results of authentication provide a mechanism to disable that
>
> We've seen how worthwhile "MAY" statements are in the spec. Just refer
> to Arjan's thread about JASPIC (still waiting for a resolution on that
> one by the way) being no longer optional for Servlet to see the problems
> that can be created by MAY statements.
I'm happy with the current MAY for that one.
> So, after reading the interesting messages of this thread, I think the
> concrete action may be to just add a little bit of spec text.
I'd be fine with that.
Mark