jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francisco Carriedo Scher <fcarrie...@gmail.com>
Subject Re: Creating users
Date Wed, 28 Sep 2011 17:47:10 GMT
Hi Angela,

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?

Thanks in advance for your attention!


2011/9/21 Angela Schreiber <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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message