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 13:59:53 GMT
Hi Angela,

I am checking now the planning board to find Access Control issue. I will
have a look to it to find out if i find developing it obtainable.

And what about wrapping the UM and AC with webservices? 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 comments once more.


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

> hi francisco
>
>
> On 9/29/11 12:33 PM, Francisco Carriedo Scher wrote:
>
>> 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?
>>
>
> the issue related to access control and jcr-remoting is
> https://issues.apache.org/**jira/browse/JCR-2113<https://issues.apache.org/jira/browse/JCR-2113>
>
> the RFC 3733 referred to in the webdav-library means that
> the library provides some initial utilities, dav properties,
> methods etc. that would be suited to implement the rfc in
> any of the server implementations present. up to now this didn't
> get enough priority, i regret so say.
>
>
>  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.
>>
>
> why not. give it a try...
> the dev list would be the right place for discussions and providing
> patches is always welcome.
>
> the implementation in jackrabbit-jcr-server specifically for
> the server that is intended to expose jcr api via http, should
> rather straight forward at least as far as the basic jcr ac
> functionality is concerned... i don't remember the very details of
> rfc 3733 but it could give some ideas on how to start.
>
> regards
> angela
>
>
>  - 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 <mailto: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> <mailto: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
>>
>>
>>
>>

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