[
https://issues.apache.org/jira/browse/SLING-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ray Davis updated SLING-1554:
-----------------------------
Affects Version/s: Extensions OpenID Authentication 0.9.0
(was: JCR Jackrabbit Server 2.0.6)
Fix Version/s: Extensions OpenID Authentication 1.0.0
(was: Extensions OpenID Authentication 0.9.0)
> Restore support for authentication-handler-specific Credentials
> ---------------------------------------------------------------
>
> Key: SLING-1554
> URL: https://issues.apache.org/jira/browse/SLING-1554
> Project: Sling
> Issue Type: Improvement
> Components: Commons
> Affects Versions: Extensions OpenID Authentication 0.9.0
> Reporter: Ray Davis
> Fix For: Extensions OpenID Authentication 1.0.0
>
>
> Jackrabbit 1.6.2's standard repository login accepted any implementation of
> Credentials. This let Sling authentication plugins define their own
> Credentials classes, and the OpenID Authentication extension creates a
> component-specific Credentials class in its "extractCredentials" method and
> checks it in "canHandle".
> Jackrabbit 2.0 changed the AbstractLoginModule to reject Credentials classes
> other than SimpleCredentials and GuestCredentials. As a result, by default
> "getCredentials" will return null if an AuthenticationHandler supplied any
> other implementation.
> A superclass of DefaultLoginModule has two ways around this: to override
> getCredentials() or to override supportCredentials(). Currently, Sling's
> PluggableDefaultLoginModule overrides getCredentials but does so only to
> allow for Sling's TrustedCredentials class.
> Either the PluggableDefaultLoginModule should let LoginModulePlugin
> implementations use their own Credentials classes (by doing the usual loop
> around "canHandle(creds)"), or the restriction should be documented and the
> OpenID extension changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
