IIRC the security workspace is not set up with access controllable nodes, so you cant use a policy on a node.
We did [1] for the securty workspace. 1 http://github.com/sakaiproject/nakamura/blob/master/bundles/server/src/main/java/org/apache/jackrabbit/core/security/user/DelegatedUserAccessControlProvider.java On 14 Sep 2010, at 05:34, Justin Edelson wrote: > Oh... I get it. There's no ACL on the user and group nodes in the > security workspace. > > But trying to apply an ACL to / or /rep:security returns an exception > > $ curl-FprincipalId=anonymous -fprivil...@jcr:all=denied > http://admin:ad...@localhost:8888/rep:security.modifyAce.html?sling.workspace=security > > <html> > <head> > <title>Error while processing security:/rep:security</title> > </head> > <body> > <h1>Error while processing security:/rep:security</h1> > <table> > <tbody> > <tr> > <td>Status</td> > <td><div id="Status">500</div></td> > </tr> > <tr> > <td>Message</td> > <td><div id="Message">javax.jcr.RepositoryException: > Failed to create ace.</div></td> > </tr> > <tr> > <td>Location</td> > <td><a href="/_rep_security" > id="Location">/_rep_security</a></td> > </tr> > <tr> > <td>Parent Location</td> > <td><a href="/" id="ParentLocation">/</a></td> > </tr> > <tr> > <td>Path</td> > <td><div id="Path">security:/rep:security</div></td> > </tr> > <tr> > <td>Referer</td> > <td><a href="" id="Referer"></a></td> > </tr> > <tr> > <td>ChangeLog</td> > <td><div id="ChangeLog"><pre></pre></div></td> > </tr> > </tbody> > </table> > <p><a href="">Go Back</a></p> > <p><a href="/_rep_security">Modified Resource</a></p> > <p><a href="/">Parent of Modified Resource</a></p> > </body> > </html> > > On 9/11/10 10:25 AM, Felix Meschberger wrote: >> Hi, >> >> Unless I am completely mistaken, the usermanager uses the request's >> session to get at the Jackrabbit UserManager to do any tasks, which is >> the absolutely correct thing IMHO. >> >> We should definitely leave this kind of access control to Jackrabbit >> (resp. the configured functionality of Jackrabbit) and not impose our >> own idea ontop of it. >> >> There is one situation where an admin session is always retrieved: The >> CreeateUser servlet. This is probably a bug and should only use an admin >> session for self-registration. >> >> Regards >> Felix >> >> Am 10.09.2010 00:47, schrieb Mike Moulton: >>> I recently had the need to get a list of users from an AJAX style client >>> and found the jackrabbit usermanager exposes this functionality at >>> system/userManager/user. As a part of this discovery, I noticed the listing >>> of JCR users is not restricted in any way. If the usermanager bundle is >>> installed, the following endpoint is open to the public: >>> http://localhost:8080/system/userManager/user.tidy.1.json, providing a >>> complete user list to anyone digging around. Any usermanager command that >>> allows modifications to the JCR first checks if the user is an admin, but >>> it seems all the read-only commands skip this check. >>> >>> Is this by intention, or was this simply missed? >>> >>> In addition, what are the thoughts on adding some sort of authorization >>> component beyond just the isAdmin check? Maybe inspecting the >>> jcr:readAccessControl / jcr:modifyAccessControl for the root node? >>> >>> -- Mike >
