>>> snip snap > > 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. > > This is wrong: An AuthenticationHandler returns an AuthenticationInfo > object which provides the JCR credentials for login (plus the > authentication type plus optionally a workspace to log in to). > > The SlingAuthenticator class uses this AuthenticationInfo to actually > log into the repository -- or with the new concept -- to get a > ResourceResolver from the factory.
That was a typo of me, sorry. I haven't meant the AuthenticationHandler but the AuthenticationSupport which really does log in but uses the AuthenticationHandler to get the AuthenticationInfo. > > > 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? > > Ehrm .. not quite. See above for the full explanation. > > > Sorry if that sounds all weired, maybe I need some directions... > > No problems, and I hope my explanation above shows this directions ... Yes, thanks. I definitively have to write a new docu page after all is committed. Because all the authentication stuff is grown over time, it got a bit confusing on the first sight. best regards mike
