Hi,
On Fri, Apr 22, 2016 at 1:29 PM, Ivar Grimstad <ivar.grimstad_at_gmail.com>
wrote:
> If I have understood correctly this isn't the case here, so authenticate
> would be a better name than doAuthenticate.
>
Okay, so I'll make a note for "authenticate" and "logout" then.
Hopefully we'll get some more suggestions, so we can truly speak of a
consensus decision ;)
(one more suggestion to consider for the validateRequest method -> login())
> If most implementations will have use for the context, which I suspect, it
> makes more sense to actually have it as a method parameter.
>
The context will almost always have to be used in the current proposal,
since it's used to set the authenticated identity. There are alternative
designs possible, of course, but that undoubtedly will require other trade
offs.
> Do we need the request/response to be available from the context, or just
> leave it to the implementer to inject it if needed?
>
Request/response are quite often needed, as the mechanism's primary task is
to interact with the user (inspecting request headers and parameters,
redirecting or forwarding, etc). There's an existing producer (build-in
Bean in the CDI spec) for the HttpServletRequest, but there isn't one for
the response.
It would be weird I think if the Security API is the spec in Java EE that
provides a HttpServletResponse producer/build-in Bean. So we'd have to ask
the CDI EG for this. But the CDI EG wants this responsibility to be with
the Servlet spec. But then, the Servlet spec would also need to provide
HttpServletRequest really (meaning transferring it from CDI to Servlet),
and that process has stalled, unfortunately.
> One case we may need to provide it through the context is if we manipulate
> it, or wrap it in some way earlier.
>
This indeed happens now, for the request.getUserPrincipal() method, which
may be non-null to indicate an authentication session is used (but we could
perhaps choose not expose this lower level detail to authentication
mechanisms).
Kind regards,
Arjan Tijms