jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lahiru Gunathilake <glah...@gmail.com>
Subject Re: Creating users
Date Tue, 11 Oct 2011 17:25:31 GMT
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