On 18 Dec 2009, at 07:20, Felix Meschberger wrote:
> Hi all,
>
> Currently Sling (the SlingMainServlet) is registered with the OSGi
> HttpService using an OSGi HttpContext whose handleSecurity method is
> implemented by means of the SlingAuthenticator class. This all is
> implemented in the Sling Engine bundle. See the code [1] and the
> documentation [2] for full details.
>
> This has a number of drawbacks:
>
> * Evolution of authentication provision and implementation
> is tied to the relatively unrelated Sling core implementation
>
> * The SlingAuthenticator class can only be used by servlets
> registered with Sling itself. Servlets registered directly
> with the OSGi HttpService have to implement the
> HttpContext.handleSecurity themselves, thus causing code
> duplication
>
> * The interaction between the SlingAuthenticator logging into
> the repository (Putting the session in a request attribute)
> and the SlingMainServlet using that session and logging it
> out after request termination is somewhat asynchronous.
>
> To remedy this situation, I propose to create a new bundle with the
> authentication stuff in the Engine bundle: The o.a.s.engine.auth and
> o.a.s.engine.impl.auth packages.
>
> This allows for re-use of the authentication mechanisms by other servlets.
>
> To enable authentication support a new Service interface is defined
> which allows to implement the handleSecurity method and which allows for
> proper cleanup at the end of the request.
>
> There are some options to consider, though, and an optimal solution
> escapes my mind right now...
>
>
> Option 1: Provide clean up API in the authentication service interface
>
> The service interface is defined as:
>
> public interface AuthenticationSupport {
> public boolean handleSecurity(
> HttpServletRequest, HttpServletResponse);
> public void endRequest(HttpServletRequest);
> }
>
> The handleSecurity method is meant to implement the
> HttpService.handleSecurity method. It is speced accordingly -- also
> requiring the request attributes to be set. Additionally, the method
> must set a ResourceResolver attribute (not a JCR session) for use by the
> client.
>
> The endRequest method must be called by the client when request
> processing has terminated. The intent is for the AuthenticationSupport
> service to cleanup -- namely logout an JCR session.
>
> The drawback of this option is, that it is assymmetric: HttpContext has
> to call handleSecurity, the registered Servlet has to call endRequest.
>
> Option 2: Implement ServletRequestListener
>
> The service interface is defined as:
>
> public interface AuthenticationSupport {
> public boolean handleSecurity(
> HttpServletRequest, HttpServletResponse);
> }
>
> The handleSecurity method is meant to implement the
> HttpService.handleSecurity method. It is speced accordingly -- also
> requiring the request attributes to be set. Additionally, the method
> must set a ResourceResolver attribute (not a JCR session) for use by the
> client.
>
> In addition the SlingAuthenticator registers itself as a
> ServletRequestListener handling the requestDestroyed method to cleanup
> any setups from the handleSecurity method, namely logging out JCR
> Session(s).
>
> The drawback of this option is, that it requires support to register a
> ServletRequestListener. This is something which is not supported by the
> HttpService spec and thus may only be supported by extended
> implementation (or any future HttpService or similar spec).
>
>
> WDYT ?
the endRequest(..) is starting to show the exposure of a request lifecycle. I
would like to see this abstracted into something like a request lifecycle
listener, so that listeners can register to perform start and end request
operations, such as completing transactions or clearing request caches, not
just clearing authentication.
At the moment we implement the above as servlet filters, which is Ok, and so
some extents arguably better as it intercepts the call stack, however it hides
the purpose of the filter.
Obviously implementation would have to guarentee that the endRequest was
called, regardless of all else that happened, (although perhaps it should
indicate failure) eg endRequest(boolean success)
----------
On the wider question of extracting the api and loosening the bindings, I agree.
Ian
>
> Regards
> Felix
>
>
> [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/engine
> [2] http://sling.apache.org/site/authentication.html
