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