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 < [email protected]> 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 <[email protected]> > > > 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 <[email protected] <mailto:[email protected] > >> > >> > >> 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 <[email protected] > >> <mailto:[email protected]> <mailto:[email protected] > >> > >> <mailto:[email protected]>>> > >> > >> > >> 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
