Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (nike.apache.org: domain of anchela@adobe.com designates
 64.18.1.25 as permitted sender)
Message-ID: <4E8461E4.2010305@adobe.com>
Date: Thu, 29 Sep 2011 14:17:40 +0200
From: Angela Schreiber <anchela@adobe.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "fcarriedos@gmail.com" <fcarriedos@gmail.com>
CC: "users@jackrabbit.apache.org" <users@jackrabbit.apache.org>
Subject: Re: Creating users
References: 
 <CAFWtOcMxZsPFAGCpte2X2HtP_x6_HUXaxuVW=F85tZWU7OdsRQ@mail.gmail.com>
 <4E786719.20309@adobe.com>
 <CAFWtOcMdEAvnp5qyYsWU8eBU5aSqdbnZw3S4LO5L8WWPyKbr1A@mail.gmail.com>
 <4E799747.3070908@adobe.com>
 <CAFWtOcPGzT9_WBX0hrtfvwYz_JTxpKk-CtUKGtiO1Fa3fQM-FA@mail.gmail.com>
 <4E835F20.1030704@adobe.com>
 <CAFWtOcPPivFwQY8=+qbtbyNC5DUsjSJKs_QsNeo3a6QizsD_Tg@mail.gmail.com>
In-Reply-To: 
 <CAFWtOcPPivFwQY8=+qbtbyNC5DUsjSJKs_QsNeo3a6QizsD_Tg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

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

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