I can create patches then to prevent anon access. What do you think about tying the authorization to existing JCR ACL's like jcr:readAccessControl or jcr:modifyAccessControl? If there is interest, I can include this in my patches.
-- Mike On Sep 9, 2010, at 5:07 PM, Justin Edelson wrote: > I can't speak to whether this was by intent or not, but I would > definitely recommend preventing anonymous access to /system. Beyond > that, it gets very application-specific quickly. > > Justin > > On 9/9/10 6:47 PM, Mike Moulton wrote: >> 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 >
