Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
From email discussion on sling-dev:
I have written some perl[0] to test getting and setting permissions on nodes[1] via the get ACL servlet, and the modifyAce.html. However, if I set the permission jcr:read on one node for admin, then subsequently set the jcr:modifyAccessControl on the same node for admin and just end up with the last permission set rather than both. Is this the intended behaviour, or should it have merged the
permissions together? The json I end up with is:
{"admin":{"granted":["jcr:modifyAccessControl"]}}
with no mention of the read permission...?
[0]
https://saffron.caret.cam.ac.uk/svn/projects/sakoader/branches/improveGenericUse/SlingPerl
[1]
SlingPerl$ perl content.pl -U http://localhost:8080 -a -D mergeTest -u admin -p admin
Content addition to "mergeTest" succeeded!
SlingPerl$ perl authz.pl -U http://localhost:8080 -u admin -p admin -D mergeTest --read -P admin
Privileges on "mergeTest" for "admin" modified.
SlingPerl$ perl authz.pl -U http://localhost:8080 -u admin -p admin -D mergeTest -v
{"admin":{"granted":["jcr:read"]}}
SlingPerl$ perl authz.pl -U http://localhost:8080 -u admin -p admin -D mergeTest --modifyACL -P admin
Privileges on "mergeTest" for "admin" modified.
SlingPerl$ perl authz.pl -U http://localhost:8080 -u admin -p admin -D mergeTest -v
{"admin":{"granted":["jcr:modifyAccessControl"]}}
Reply from Eric Norman:
You are correct, the ModifyAceServlet does not merge the existing privileges with the submitted privileges. If there is an existing ACE, it is replaced with a new one containing only the privileges that were submitted.
I agree with you that it should probably leave the existing privleges that did not have a value ("granted", "denied", or "none") submitted .