On Fri, Dec 18, 2009 at 2:20 AM, Felix Meschberger <fmesc...@gmail.com>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 ?
>
> Regards
> Felix
>
>
> [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/engine
> [2] http://sling.apache.org/site/authentication.html
>
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).
This may be problematic because you'd end up logging into the repository
twice for a Sling request.
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.
Justin
