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