first of all: "hello" to all subscribers from my side :-) >interface CredentialValidator +1
> One issue remains: disposal of the Session placed into the > AuthenticationInfo object by the validate method. But this can be > solved, I am sure ... isn't this session "just a session" and hence times out after a awhile? Kind regards Clemens > -----Original Message----- > From: Felix Meschberger [mailto:[email protected]] > Sent: Monday, March 15, 2010 8:15 AM > To: [email protected] > Subject: Re: Merging Sling API and Commons Auth API > > > Hi, > > On 14.03.2010 07:41, Mike Müller wrote: > >>> while working on the ResourceResolverFactory I noticed some > >> problems. > >>> We plan to let the SlingAuthenticator directly use the > >>> ResourceResolverFactory to authenticate. This removes all > >> dependencies > >>> to JCR from the authentication and gives us much more flexibility. > >>> > >>> However, currently the constants for things like user, > >>> password etc are > >>> defined in the AuthenticationInfo. In fact, these are > constants that > >>> should be defined by the ResourceResovlerFactory because > this is the > >>> service that is used for authentication. > >>> > >>> I briefly discussed this with Felix and we both came to the > >> conclusion > >>> that in fact the commons auth is not really commons :) It > is more an > >>> auth api for Sling. > >>> > >>> Therefore it seems to make sense to move the api from commons > >>> auth into > >>> the Sling API. So we have one single API to deal with. The > >>> implementation of the auth would stay in a separate > bundle (together > >>> with the compatibility stuff for the older engine auth). > >>> > >>> Before discussing the details like which packages to use > >> etc. what do > >>> you think in general about this? > >>> > >>> Carsten > >> > >> > >> +1 to move the commons auth into the Sling API in general. > >> But I would like to decouple the ResourceResolverFactory > >> completly from > >> Authentication. It seems that this coupling only exists because of > >> the circumstances of the JCR (to return a JcrResourceResolver the > >> ResourceResolverFactory needs to login into the JCR). From a more > >> abstract view Authentication has not certainly to be coupled with > >> the Factory which returns the ResourceResolver. I know there's the > >> problem with performance (depending on the implementation maybe > >> two logins and therefore two JCR sessions), but I think it would > >> be worth to stay two steps back and discuss the new > Authentication and > >> the new ResourceResovlerFactory once again. We do have now the > >> possibility to do that, because both concepts are new and not > >> released. > >> > >> best regards > >> mike > > > > As you probably know, this is not the first time I come up with > > this [1]. At the risk of being a little bit cumbersome, I really > > think we could design a clean API where authentication and > > the getting of a resource resolver is completely decoupled without > > loosing performance. The API doesn't tell us how we have to > > implement it (but is has to give us the chance to implement it > > without loosing performance ;-). I would propose to first define > > how a "brave world" API would look like and go from there. > > WDYT? > > > > [1] http://markmail.org/message/bwgrbhwlsi5ekenn > > My biggest concern with this was (and still is) loss of performance if > logging two login's would be required for each request. We can "fix" > this issue, if we defined an API to act as an intermediary, e.g. > something like: > > public interface CredentialValidator { > public AuthenticationInfo validate( > AuthenticationInfo credentials) > throws LoginException; > } > > This service interface would be implemented by a JCR based > implementation using Repository.login to valid and would be > used by the > SlingAuthenitator to validate the credentials. > > The AuthenticationInfo returned might contain the session acquired > during validation and be set as a request attribute. That request > attribute would be picked up by the SlingMainServlet to hand > over to the > ResourceResolverFactory.getResourceResolver(Map) method. > > One issue remains: disposal of the Session placed into the > AuthenticationInfo object by the validate method. But this can be > solved, I am sure ... > > More details (aka words) at [1] > > Regards > Felix > > [1] http://cwiki.apache.org/SLING/user-authentication.html > > > > > best regards > > mike > > > > > >
