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 Tue, 11 Oct 2011 21:42:24 GMT
That's it... Neither user management nor access control are currently
available through RMI or Webdav. As you probably already have read from
previous emails such functionalities are only available when operating JR as
embeded repository (starting it through your Java code).


2011/10/11 Lahiru Gunathilake <glahiru@gmail.com>

> Hi Francisco,
>
> So can some user assume that creating a new user for a remote client is
> currently impossible in JR without changing JR 2.2.7 release ?
>
> Regards
> Lahiru
>
> On Thu, Sep 29, 2011 at 9:59 AM, Francisco Carriedo Scher <
> fcarriedos@gmail.com> wrote:
>
>> 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
>> >>
>> >>
>> >>
>> >>
>>
>
>
>
> --
> System Analyst Programmer
> PTI Lab
> Indiana University
>
>

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