Hi,
On 21.12.2009 08:47, Carsten Ziegeler wrote:
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 ?
I think creating an own bundle makes definitly sense - as you outlined
both options (API or listener) have pros and cons; from a developer
perspective a favour the API way as it is easier to forget a
configuration of a listener than to call the api. In the end we could
provide both ways by having the api with the endRequest(...) method and
providing a listener which just calls this method.
For the package name o.a.s.engine.auth I'm not sure :) wouldn't this be
something which has common character? And maybe might be used by the
Felix web console as well? So I would favour something like
o.a.s.commons.auth.
Correct. My intent is to guarantee backwards compatibility -- mainly for
the exported packages, where we have implementations
(AuthenticationHandler) and users (Authenticator) out in the wild.
Maybe we could move the package to the location (o.a.s.commons.auth
sounds good) and provide the old API for backwards compatibility.
Regards
Felix
Regards
Carsten
