Looks great, Eric -- thank you for jumping through all those hoops.
I'll incorporate the new logic into my proposed patch. Given the added
complexity of disaggregation / re-aggregation, I think there's even more
reason to get this code into a central location for use by server-side
developers.
Best,
Ray
On 2/23/10 8:48 PM, Eric Norman wrote:
Ray,
I applied a new patch in r915670.
Can you please verify that this addresses your concerns?
Thanks!
Eric
On Tue, Feb 23, 2010 at 7:42 PM, Eric Norman<[email protected]>wrote:
Hi Ray,
Thanks for testing and reporting this. You raise a good point.
The ModifyAceServlet should handle updates involving aggregate privileges
transparently. I'll re-open SLING-997 and work on an updated fix to address
your scenario.
Regards,
Eric
On Tue, Feb 23, 2010 at 3:32 PM, Ray Davis<[email protected]> wrote:
While scoping this out I bumped into some behavior that surprised me. The
idea of SLING-997 is to merge newly specified privileges with any existing
ACEs for the principal. ModifyAceServlet does this by remembering any
existing ACE-included privileges which aren't mentioned *by name* in the
servlet input, merging them with the servlet-specified privilege lists, and
then adding the merged lists as two ACEs, first the grants and then the
denies. Jackrabbit's handling of aggregate privileges can put an interesting
twist on this, though:
===
curl -u admin:admin http://localhost:8080/content/anode.acl.json
{"inst":{"granted":["jcr:read"],"denied":["jcr:write"]}}
# The next request will have no effect because denied "write" will be
applied after granted "modifyProperties":
curl -u admin:admin -FprincipalId=inst -fprivil...@jcr:modifyProperties=granted
http://localhost:8080/content/anode.modifyAce.html
curl -u admin:admin http://localhost:8080/content/anode.acl.json
{"inst":{"granted":["jcr:read"],"denied":["jcr:write"]}}
# This will have no effect because "all" is not stored in an ACE:
curl -u admin:admin -FprincipalId=inst -fprivil...@jcr:modifyProperties=granted
-fprivil...@jcr:all=none
http://localhost:8080/content/anode.modifyAce.html
curl -u admin:admin http://localhost:8080/content/anode.acl.json
{"inst":{"granted":["jcr:read"],"denied":["jcr:write"]}}
# This is the only way to handle it:
curl -u admin:admin -FprincipalId=inst -fprivil...@jcr:modifyProperties=granted
-fprivil...@jcr:write=none
http://localhost:8080/content/anode.modifyAce.html
curl -u admin:admin http://localhost:8080/content/anode.acl.json
{"inst":{"granted":["jcr:modifyProperties","jcr:read"]}}
==
Does this seem OK, so long as the ModifyAceServlet JavaDoc and
http://sling.apache.org/site/managing-permissions-jackrabbitaccessmanager.htmlget
updated to explain the behavior? Or should Sling try to disaggregate
privileges when checking for changes?
Thanks,
Ray
On 2/22/10 9:53 AM, Ray Davis wrote:
I happened to be looking at the ModifyAceServlet issue described at
SLING-997 late last week and noticed almost exactly the same logic
(except without the bug) in
jcr/contentloader/internal/DefaultContentCreator. In the Sakai 3
project, Ian added a utility method to consolidate the same rather
complex logic of replacing access controls for a specific Principal on a
specific path, and it's proven very popular among service developers.
I'd like to try submitting a similar utility method to Sling, but wanted
to check with the development team first in case there's a conflict with
other near-term authz tasks.
Thanks,
Ray
