You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Ray Davis (JIRA)" <ji...@apache.org> on 2010/06/11 18:32:14 UTC

[jira] Created: (SLING-1554) Restore support for authentication-handler-specific Credentials

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
            Reporter: Ray Davis


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.


[jira] Updated: (SLING-1554) Restore support for authentication-handler-specific Credentials

Posted by "Ray Davis (JIRA)" <ji...@apache.org>.
     [ 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: JCR Jackrabbit Server 2.0.6

> 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: JCR Jackrabbit Server 2.0.6
>            Reporter: Ray Davis
>
> 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.


[jira] Updated: (SLING-1554) Restore support for authentication-handler-specific Credentials

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger updated SLING-1554:
-------------------------------------

    Component/s: Authentication
                     (was: Commons)

> 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: Authentication
>    Affects Versions: Extensions OpenID Authentication 0.9.0
>            Reporter: Ray Davis
>             Fix For: 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.


[jira] Closed: (SLING-1554) Restore support for authentication-handler-specific Credentials

Posted by "Felix Meschberger (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Felix Meschberger closed SLING-1554.
------------------------------------


Close after release

> 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: Authentication
>    Affects Versions: Extensions OpenID Authentication 0.9.0
>            Reporter: Ray Davis
>             Fix For: 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.


[jira] Updated: (SLING-1554) Restore support for authentication-handler-specific Credentials

Posted by "Ray Davis (JIRA)" <ji...@apache.org>.
     [ 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.


[jira] Resolved: (SLING-1554) Restore support for authentication-handler-specific Credentials

Posted by "Ray Davis (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SLING-1554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ray Davis resolved SLING-1554.
------------------------------

    Fix Version/s: Extensions OpenID Authentication 0.9.0
       Resolution: Fixed

OpenID integration on Jackrabbit 2 was fixed by SLING-1374. That fix demonstrates an easy workaround to the described issue: instead of returning a "branded" implementation of Credentials, store and check a "branded" attribute on a SimpleCredentials object.

> 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: JCR Jackrabbit Server 2.0.6
>            Reporter: Ray Davis
>             Fix For: Extensions OpenID Authentication 0.9.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.