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
