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 <anchela@adobe.com <mailto:anchela@adobe.com>>
>
>     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
>
>