Hi Ian, There was an Engine 2.0.6 release, which still contains the old authentication API.
The combo Engine trunk plus Commons Auth trunk is basically an extended situation of the Engine 2.0.6 release and all the 2.0.6 authentication functionality still works. Hope this helps. Regards Felix On 06.01.2010 12:07, Ian Boston wrote: > Felix, > Were there recent releases of the bundles in question before this change was > made. I am < 1 week away from cutting a release and we have some major bits > of work in the AuthN area, including container and CAS authn modules. I > suspect that the porting effort is going to be minimal but the guys who did > our CAS authn code have been moved off the project. > > Ian > On 6 Jan 2010, at 10:49, Felix Meschberger wrote: > >> Hi all, >> >> I have now committed the changes required for SLING-966 [1]. >> >> So, if you upgrade the Sling Engine to the latest trunk, you should also >> install the new Commons Auth bundle. >> >> Your existing AuthenticationHandler implementations will still be >> working. I have upgraded our own HTTP Basic and OpenID Authentication >> Handler implementations to make use of the new API from Commons Auth. >> >> I now will turn to documentation and try to clarify what has been >> written in [2]. >> >> Regards >> Felix >> >> [1] https://issues.apache.org/jira/browse/SLING-966 >> [2] http://sling.apache.org/site/authentication.html >> >> On 02.01.2010 16:29, Felix Meschberger wrote: >>> Hi, >>> >>> I have now implemented a prototype and attached the patch (againt Sling >>> trunk) to SLING-966 [1]. >>> >>> This patch relies on ServletRequestListener support (and a finalize() >>> method) for Session clean up. We could also (readd) the Sessio.logout >>> call in the Engine's SlingMainServlet for now... (though I would really >>> prefer pure ServletRequestListener support). >>> >>> This patch does not yet require the ResourceResolver[Factory] stuff but >>> of course would probably benefit from it as been pointed out on this thread. >>> >>> WDYT ? >>> >>> Regards >>> Felix >>> >>> [1] https://issues.apache.org/jira/browse/SLING-966 >>> >>> On 18.12.2009 08: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 ? >>>> >>>> Regards >>>> Felix >>>> >>>> >>>> [1] https://svn.apache.org/repos/asf/sling/trunk/bundles/engine >>>> [2] http://sling.apache.org/site/authentication.html >>>> > >
