[
https://issues.apache.org/jira/browse/SLING-6357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15728501#comment-15728501
]
Julian Sedding edited comment on SLING-6357 at 12/7/16 11:19 AM:
-----------------------------------------------------------------
Fixed in [r1773046|https://svn.apache.org/r1773046].
[~bdelacretaz], [~rombert] I would appreciate if you could take a look at the
changes. I successfully ran a full build with these changes. Anyway, I'll leave
the issue open for a while in case there are still problems.
Note, I moved the *default whitelist* into a provisioning model in
{{launchpad/builder}}. Let me know if you think this is wise or not.
was (Author: jsedding):
Fixed in [r1773046|https://svn.apache.org/r1773046].
[~bdelacretaz], [~rombert] I would appreciate if you could take a look at the
changes. I successfully ran a full build with these changes. Anyway, I'll leave
the issue open for a while in case there are still problems.
> Allow to extend LoginAdminWhitelist with multiple configurations
> ----------------------------------------------------------------
>
> Key: SLING-6357
> URL: https://issues.apache.org/jira/browse/SLING-6357
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Base 2.4.2
> Reporter: Julian Sedding
> Assignee: Julian Sedding
> Priority: Blocker
> Fix For: JCR Base 3.0.0
>
>
> As [discussed on the mailing
> list|http://sling.markmail.org/thread/7xfcefaufczvsdgk], it would be
> desirable to allow multiple configurations to contribute to the
> {{LoginAdminWhitelist}}.
> This issue is marked *blocker*, as the current implementation was not yet
> released, thus allowing arbitrary changes without backwards compatibility
> headaches.
> I propose to remove the {{whitelist.bundles.default}} and
> {{whitelist.bundles.additional}} properties and replace them by "additional
> configurations" that each allow to provide a list of whitlisted bundle
> symbolic names.
> In the main configuration for {{LoginAdminWhitelist}} I propose to retain the
> flag to bypass the whitelist completely.
> I am uncertain, whether we really need the whitelist regexp for testing, as
> it is fairly simple to list a hand full of required bundles. If we keep it, I
> suggest to make its metatype private.
> Optionally, we could consider the possibility to allow configuring a list of
> required "additional configurations". I would leave this until we find a real
> requirement for this, as it would complicate the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
