On 12/22/09 9:52 AM, Felix Meschberger wrote:
I'm a tad weary of introducing a dependency on a non-standard extension of
HttpService in such a critical piece of functionality. I'm curious if
there's a way to perform the authentication step *without* adding a
ResourceResolver as a request attribute (and thus eliminating the need to do
post-request cleanup) and then push the creation of the ResourceResolver
down to happen inside SlingMainServlet (or thereabouts).
That's what we already do today: we login from within the
HttpContext.handleSecurity method and (currently) place the JCR Session
as a request attribute -- much like the HttpService spec expects the
user name, authentication type and (optionally) the UserAdmin
Authorization object as request attributes.
Right. I was asking about not placing the JCR Session as a request
attribute yet still using the repository to authenticate. This seems
like the easiest past for non-Sling servlets to deal with.
I just don't think it's reasonable to expect that if I create a Servlet and
register it with HttpService directly, that I get some special Sling
goodness automagically.
Not really. If you register a servlet you have to provide an HttpContext
object. If you don't provide an object, a default implementation will be
used.
For Sling, we provide a special HttpContext object (actually the
SlingMainServlet is also the HttpContext object) implementing the
handleSecurity method as described.
So, servlets registered with the default context or with their own
implementations do not have to do any thing. Only servlets registered
with an HttpContext object whose handleSecurity method uses the new
authentication service will have to behave ...
But it's typically something *other than* the Servlet which does this
registration, at least in my experience (like an Activator). In other
words, the Servlet is not necessarily aware of the semantics of the
HttpContext with which it has been registered. Nor, I would argue,
should it be.
But yes, I agree, that this is not nice ... Being able to inject a
Servlet API 2.4 request listener would make lives easier since the
authentication service could register as such and cleanup up terminated
requests. (we had a thread on servlet API listeners once [1], maybe we
should pick this up again and think about to build an extension for the
HttpService spec to dynamically register servlet API listeners ....)
+1 to a) extending Felix's ExtHttpService to include request listeners
and b) getting ExtHttpService to be the basis for HttpService v2 (or
whatever).
Justin
