You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "angela (JIRA)" <ji...@apache.org> on 2016/08/09 09:28:20 UTC
[jira] [Comment Edited] (SLING-5792) API to manage Authentication
Requirement
[ https://issues.apache.org/jira/browse/SLING-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15413272#comment-15413272 ]
angela edited comment on SLING-5792 at 8/9/16 9:27 AM:
-------------------------------------------------------
[~cziegeler] thanks for the review. Regarding your questions/comments:
- yes, the auth-requirements associated with a client bundle should be removed as soon as the client bundle is gone. that would also be backwards compatible wrt the way additional auth-requirements are plugged today using an implementation detail of the {{SlingAuthenticator}} and which IMHO should be replaced and deprecated once this API makes it into the sling-auth bundle.
- I am perfectly fine using another type of key or no key at all... the main reason for using it was the this is the way it's done today in the {{SlingAuthenticator}} implementation and didn't want to change the overall logic. But if the current way of adding auth-requirements is in general considered to be troublesome (it's not my design so I can't decide this... just seeing that it's not optimal from a scalability/performance/API point of view), it would obviously be better to do it right. Let me try to come up with an alterative approach.
was (Author: anchela):
[~cziegeler] thanks for the review. Regarding your questions/comments:
- yes, the auth-requirements associated with a client bundle should be removed as soon as the client bundle is gone. that would also be backwards compatible wrt the way additional auth-requirements are plugged today using an implementation detail of the {{SlingAuthenticator}} and which IMHO should be replaced and deprecated once this API makes it into the sling-auth bundle.
- I am perfectly fine using another type of key or no key at all... the main reason for using it was the this is the way it's done today in the {{SlingAuthenticator}} implementation and didn't want to change the overall logic. But if the current way of adding auth-requirements is in general considered to be troublesome, it would obviously be better to do it right. Let me try to come up with an alterative approach.
> API to manage Authentication Requirement
> ----------------------------------------
>
> Key: SLING-5792
> URL: https://issues.apache.org/jira/browse/SLING-5792
> Project: Sling
> Issue Type: Sub-task
> Components: Authentication
> Reporter: angela
>
> Apart from the constant {{AuthConstants.AUTH_REQUIREMENTS}} there is no public API available that allowed applications to change the list of authentication requirement entries.
> Instead, applications need to know and rely on implementation details, which not only includes registering services with the {{AuthConstants.AUTH_REQUIREMENTS}} property included but also know about the required format of the property, which from my point of view should be and remain an implementation detail of {{org.apache.sling.auth.core.impl.SlingAuthenticator}}, which IMO should not be considered public API.
> To me it would feel more natural if there existed a {{AuthenticationRequirement}} interface defining methods to extend/update/clear the auth-requirements bound to a particular service reference and having {{org.apache.sling.auth.core.impl.SlingAuthenticator}} implementing that interface.
> Doing so, might also be beneficial from a performance/scalability POV but I would like to cover that in a separate sub-task.
> Proposal for this sub-tasks will follow as I am moving forward.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)