hi francisco
your observation was fully right. I have just tested it and now i am able now to deal with users and permissions in the dummy-locally-accessed repository i used to learn about access control in JR. But now i am trying to extrapolate it to my previously working repositories, which are accessed through Webdav and the class of the obtained session object (Session session = JcrUtils.getRepository("http://localhost:8080/server";)) is not a JackrabbitSession class, but a SessionImpl class object (which did not work in my previous tests).Is there a way to get working access control (as in my tests) when the repository is obtained through Webdav?
unfortunately neither access-control nor user management is available when using jcr-remoting via webdav. sorry angela
Thanks in advance for your attention! 2011/9/21 Angela Schreiber <[email protected] <mailto:[email protected]>> hi francisco it seems to me that the principal resolution doesn't work properly. that's why you get an access control exception upon editing ACLs and cannot login to the repo. i assume that you are using a default repository setup without specifying custom principal providers. is that correct? The object um is a UserManagerImpl object obtained through an admin session: new UserManagerImpl((SessionImpl) session, "admin") that's probably the culprit. you should use if (session instanceof JackrabbitSession) { UserManager umgr = ((JackrabbitSession) session).getUserManager(); } instead of manually creating the user manager instance and relying on a specific implementation. the explanation was as simple as that: unless specified otherwise the DefaultSecurityManager builds a security setup that stores users in a separate workspace. all the depending modules (login, ac evaluation etc) then rely on that setup... however, if you create the user manager instance manually you simply store the users in the workspace of the editing session -> the user nodes exist but the principal provider (and the user-manager you would obtain from the session) look for them in a different place/workspace. if you wish to keep the users separate for each workspace instead of keeping them in a dedicated workspace you can use the alternative implementation (-> UserPerWorkspaceSecurityManage__r). but still you should refrain from creating the user manager instance manually and use the API instead. hope that helps angela
