> On 31.12.2009 14:49, Mike Müller wrote: > > Hi > > > >> On 28.12.2009 17:08, Carsten Ziegeler wrote: > >>> When we're doing changes in this area, we might also look > >> at the same > >>> time at one of the things which is on our todo list for a > >> long time :) > >>> > >>> The basic question: how to get a resource resolver? > >>> > >> (http://mail-archives.apache.org/mod_mbox/incubator-sling-dev/ > > 200811.mbox/%3c491727d7.4070...@gmail.com%3e) > > > >> Yes, we should definitely pick this up again .... > > > >> > >> >From a Sling perspective I guess after authentication happend, a > >>> resource resolver for the current user is available (somehow) - we > >>> shouldn't use the session approach like we have now. > Therefore looking > >>> at how to create a resource resolver from some factory > might be help here. > > > >> Agreed, regardless of the above the standalone authenticator will > >> provide a ResourceResolver and not a Session as a request > attribute. > > > > At the risk of coming a little bit late into this > discussion I nevertheless > > try to give my point of view. I really think while changing > the authentication > > process we should consider of implementing what Felix > proposes on [1] for > > an ResourceResolverFactory. I would like to have the > authentication process > > even more decoupled from JCR and the ResourceResolver. The > authentication > > process should authenticate the user and that's it. To > force this process also > > to set an attribute with the ResourceResolver doesn't make > sense in every > > case. > > Conceptionaally, this is correct, and I agree -- and from the > bottom of > my conceptionally correct heart, we would have to do this, but .... > > > To be honest I think the only reason to do this is to get a better > > performance because the JCR session can be reused. > > Performance is one aspect in this equation (a very important one, > though). Another aspect is, that the authentication handlers extract > credentials from the request which are used (a) to validate the > requestor's identity and (b) to actually get access to the > system/repository. > > If we go conceptionally clean, we would have to extract credentials > twice (duplicate implementation ? multiple uses of the same > implementations ? how ?). So we would probably end with an even bigger > "mess". > > > But what if the authentication > > process has nothing to do with the JCR, what if someone > authenticate to a separate > > system. It would be possible to use Sling in that case, but > the implementation > > of the AuthenticationSupport has to allocate an > ResourveResolver which should > > be the work of the new ResourceResolverFactory ([1]). That > doesn't mean that > > the implementation AuthenticationSupport can not put a > ResourceResolver or > > whatever as an attribute in the context, but it shouldn't > forced to do so. > > AuthenticationSupport should only be responsible to put > some basic information > > about the authentication into the context (like username, > userid, authtype). > > Yes and/or now. Yet, Sling is centered around having a > ResourceResolver > available to process requests. So it is IMHO ok for the > AuthenticationSupport class to not only handle credential > extraction but > also provisioning of the ResourceResolver to be used for > request handling. > > As such this is an extension to the HttpContext.handleSecurity > specification, which mandates the user name, authentication type and > (optionally) the OSGi Authorization object.
Ok, I agree on this. Sling in this case not only expects a logged in user, but also a ResourceResolver because Sling is very resource centric. Sounds reasonable. With that point of view the ResourceResolverFactory is just a convenience service from Sling to log into the JCR and get the JCRResourceResolver, via the Sling implementation of ResourceProviderFactory which tries getResourceProvider(Map<String, Object> credentials) if credentals are present and getAnonymousResourceProvider(Map<String, Object> credentials) if no credentials are present. I guess I didn't get that right, because in this case the paramter "credentials" is needless on that method? Or is it used to put the JCR session into the method? Just to make sure I understand it right I try to summarize: An implementation of AuthenticationHandler should use the Sling service ResourceResolverFactory and call getResourceResolver(credentials) on it to get the ResourceResolver. The Sling ResourceResolverFactory itself tries to get ResourceProviders via the one ore more ResourceProviderFactory implementations providing the JCR session as an attribute in the credentials map. The Sling implementation of ResourceProviderFactory would assure that all already existing ResourceProvider implementations (which are registered) will get collected. With the new ResourceProviderFactory it would be possible to bring some new ResourceProviders in, which aren't registered as ResourceProvider implementations in OSGi but implement ResourceProvider. Is that right? Sorry if that sounds all weired, maybe I need some directions... best regards mike
