Hi,
On 22.12.2009 22:07, Justin Edelson wrote:
> 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.
Yes. If we can "fix" the lifecycle issue of cleaning up the session (or
the resource resolver or whatever) it does not hurt to put it into the
servlet context for the servlet to consume and use it.
>>> 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.
That's exactly a problem ... The longer I think of it, the longer I
doubt the API solution of explicit cleanup is a good idea ...
>> 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).
Ok, I am working on a prototype to extend the new Felix HttpService
implementation to support Servlet API listeners using the whiteboard
pattern.
So here is my updated for cleanup solution:
* The authentication bundle registers a ServletRequestListener which
cleans up the session/resourceresolver/whatever when the request
terminates.
* As a safety net for environments where ServletRequestLister
whiteboard registration is not supported is implemented using the
Object.finalize() method.
WDYT ?
Regards
Felix
>
> Justin
>
