Angela Schreiber created SLING-8766:
---------------------------------------
Summary: AclVisitor.setPrincipalAcl: be more lenient with
unsupported principals
Key: SLING-8766
URL: https://issues.apache.org/jira/browse/SLING-8766
Project: Sling
Issue Type: Improvement
Components: Repoinit
Reporter: Angela Schreiber
i noticed the following potential for improvement with
{{AclVisitor.setPrincipalAcl}} when testing it in an AEM upgrade scenario. due
to the fact that repo-init doesn't verify the _intermedidatePath_ when a
user/group to be created already exists but happens to be located at the
different subtree, {{AclVisitor.setPrincipalAcl}} may fail upon upgrade _if_
the existing principal turns out to be not supported. this happens irrespective
of the fact that the repo init statements were perfectly fine if run initially.
example with filter configured with supported path
_/home/users/system/principalbased_
{code}
create service user foo with path system/principalbased
set principal ACL for foo
allow jcr:read,rep:write on /content
end
{code}
if 'foo' already existed at _/home/users/system/elsewhere_ the repo init code
does make an attempt to move 'foo' to the new location and is fine with 'foo'
existing. however, the ac-setup will fail.
i would suggest to improve this by log.INFO that no
{{PrincipalAccessControlList}} can be found instead of throwing
{{IllegalStateException}}. In the subsequent access control setup verify if an
equivalent effective {{AccessControlEntry}} is present and only throw the
exception if no such entry exists, meaning that the effective access control
setup resulting from repo-init is incomplete.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
