[
https://issues.apache.org/jira/browse/SLING-5792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15383894#comment-15383894
]
ASF GitHub Bot commented on SLING-5792:
---------------------------------------
GitHub user anchela opened a pull request:
https://github.com/apache/sling/pull/153
SLING-5792, SLING-5868, SLING-5795
## SLING-5792: API to manage Authentication Requirement
### Changes
- new interface 'AuthenticationRequirement'
- implemented by SlingAuthenticator
- additionally: annotations with helper classes in the impl package to
improve readability
### Notes
with the implementation in SlingAuthenticator the values in the 'props' map
change from array of AuthenticationRequirementHolder to a Set, which IMO
corresponds better to the PathBasedHolderCache, which at some point has changed
from ArrayList to SortedSet... but that for sure requires a careful review
(also from a performance PoV)
### TODO
- the original code synchronized on 'props' before updating the
PathBasedHolderCache, which itself was synchronized. That looks troublesome to
me and with the patch this is separated.
- I would like to write some benchmarks to be able to compare performance
of AuthenticationRequirement vs. the ServiceListener approach as well as the
effect of moving from array to Set in the props-map. But: I couldn't find the
right way of doing this in Apache Sling (see also SLING-5791 for a specific
issue).
## SLING-5795 and SLING-5868
### Changes
- new module 'org.apache.sling.auth.requirement' in the contrib/auth space
- new public API 'LoginPathProvider'
- implementation based on Jackrabbit Oak that allows to mark subtrees with
the set of configured supported paths to require authentication including an
optional login path.
### TODO
- currently snapshot dependency to 'org.apache.sling.auth.core' due to
usage of 'AuthenticationRequirement'
- repo-init that defines the service-user required for the default
implementation
- Oak index definition that prevents traversal for initial query
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/anchela/sling trunk
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/sling/pull/153.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #153
----
commit b11eaaa043a406ccac16a07edec0c7815d1cba5a
Author: angela <anch...@adobe.com>
Date: 2016-07-19T08:23:44Z
SLING-5792 : API to manage Authentication Requirement
commit 28c147c387b997e3d2106e1ad82d2b35e50388a3
Author: angela <anch...@adobe.com>
Date: 2016-07-19T09:14:24Z
SLING-5868 : API to define and retrieve login path with along with
authentication requirements
SLING-5795: Allow for adding/removing individual
AuthenticationRequirementHolder entries
----
> 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)
