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 Thu, 29 Sep 2011 10:33:29 GMT
Hi Angela,

then, taking into account the other options (please tell me if i am wrong)
if i obtain the repository object through:

- Webdav: user management and access control is not available.
- RMI: user management and access control is not available either.
- JNDI: idem as the same point (since the repository object is located
through JNDI tree but it is finally remotely operated using RMI, isn't it?)

I have checked the JIRA for Jackrabbit (until 2008) and i did not find any
attemp to implement access control nor user management through RMI nor
Webdav. Anyway i found "RFC 3744 (Access Control Protocol)" support  mention
inside README file in the jackrabbit-webdav project. Would this last option
fit my purposes?

Finally, right now i consider the following alternatives:

- extending JR remoting through RMI or Webdav to support UM and AC. I would
like to contribute back to JR project but i am not sure if i am the
appropiate one to implement such extension.

- wrap the UM and AC with webservices but, would that mean performing all
the operations through WS? Let me explain: since the UM and AC operations
require the repository to be started locally, my doubt is: would work
enabling the desired modules (jackrabbit-webdav for Webdav or
jackrabbit-jcr-rmi for RMI) to have AC and UM working through WS and other
functionalities through Webdav / RMI?

Thank you very much for your attention, it helps a lot!

2011/9/28 Angela Schreiber <anchela@adobe.com>

> 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<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

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