[
https://issues.apache.org/jira/browse/SLING-5795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15384448#comment-15384448
]
angela commented on SLING-5795:
-------------------------------
see SLING-5792 for pull request
> Allow for adding/removing individual AuthenticationRequirementHolder entries
> ----------------------------------------------------------------------------
>
> Key: SLING-5795
> URL: https://issues.apache.org/jira/browse/SLING-5795
> Project: Sling
> Issue Type: Sub-task
> Components: Authentication
> Reporter: angela
>
> Today the {{SlingAuthenticator}} comes with a
> {{SlingAuthenticatorServiceListener}}, that listens for all services that are
> registered with an {{AuthConstants.AUTH_REQUIREMENTS}} property. This allows
> for arbitrary services to extend the list of authentication requirements
> originally intended to be configured with the {{SlingAuthenticatior}}.
> The implementation consequently requires those services to provide their full
> list of auth-requirements: this not only forces the services to recompute
> that information but also forces the {{SlingAuthenticatorServiceListener}} to
> process the whole information upon every single change (see
> {{SlingAuthenticatorServiceListener.addService}} and
> {{SlingAuthenticatorServiceListener.removeService}}, which also includes an
> update of the {{PathBasedHolderCache}}.
> At a Adobe we make use of this ability in a service that may contain several
> thousand requirement entries which in addition are prone to frequent changes,
> which IMO is not super-optimal with the implementation at hand.
> This assessment is not yet backed with decent performance testing, but based
> on what I found while trying to rewrite that particular service to address
> known issues.
> To summarize: What I have been looking for was the ability to inform the
> listener about a single entry that would need to be added or removed from the
> list of auth-requirements collected (and registered) by my service, without
> having to compute (or cache) the complete list and without having all items
> associated with my service being processed over and over again.
> Maybe envisioning SLING-5792 would offer the opportunity to also reconsider
> this wish.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
