[
https://issues.apache.org/jira/browse/SLING-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12898673#action_12898673
]
Mike Müller commented on SLING-1593:
------------------------------------
If I get you right, you mean that it's optional to implement the interface. If
a service implements it and throws a LoginException the ResourceResolverFactory
is not called. Did I get you right?
But why you like to choose not to implement the interface in the case of the
JcrResourceResolverFactoryImpl?
One use case is to have a custom CredentialsValidator which validates the user
against an external API and creates an AuthenticationInfo with a complementary
user from the JCR. This could be done also with a custom LoginModulePlugin, but
the goal is to be independent from jackrabbit internals. The same could be
reached by implementing AuthenticationHandler#extractCredentials in a way to
return the desired credentials but this would be rather a hack.
> Decouple authentication mechanism from JCR
> ------------------------------------------
>
> Key: SLING-1593
> URL: https://issues.apache.org/jira/browse/SLING-1593
> Project: Sling
> Issue Type: Improvement
> Components: API, Commons, JCR
> Reporter: Mike Müller
> Assignee: Mike Müller
> Fix For: Commons Auth 1.0.0
>
> Attachments: sling-1593.patch, sling-1593b.patch
>
>
> Felix made a good proposal how to decouple the authentication mechanism from
> JCR at [1] after the discussion at [2]. The remaining issue there was how to
> ensure JCR sessions which are placed into AuthenticationInfo be closed. To
> solve that issue we now can use the new SlingRequestListener [3].
> [1] https://cwiki.apache.org/SLING/user-authentication.html
> [2] http://markmail.org/message/aovh7lll4w6uwepv
> [3] https://issues.apache.org/jira/browse/SLING-1576
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
