hi ryan, > Thanks for the reply. What I'm gathering from your post and re-reading the > spec sections on workspaces is that the actual use of workspaces is more of > an exotic case that is probably not applicable or desireable in my > situation. hmm... the "per-user-workspace" is actually one of the usecases that we had in mind.
> What it sounds like I want to do is use one workspace and > implement my own security layer over the top of that to protect access to > resources. For example, to keep x:jane out of x:bob's stuff. So, when > either x:jane or x:bob logs in, they get the same workspaces with the same > root, but their access to resources would be restricted. i would argue that it is a matter of the degree of separation between the user-directories. lessons learned from "unix user home dirs" probably points for most applications into the direction of access control instead of separate workspaces. > From a jackrabbit standpoint, it looks like that means implementing my own > AccessManager. Does anyone know if there is a good reason that the > AMContext has no access to the current Session or Repository? If I want to > implement a security mechanism where the permission data is actually stored > in the repository as well, it would be handy to have access to the > Repository or Session from AccessManager. Although, I guess there's no > reason I couldn't get the same Repository instance from JNDI in my own > AccessManager implementation. Thinking out loud at this point... actually, we implemented something for crx that may be what you are looking for, which you can find on http://jcr.day.com i tried to model the situation with /users/jane and /users/bob and applied an acl that may be what you are looking for. you can login either with bob, jane or admin (password = username) to see if that meets your requirements. from a ui perspective we are redoing the whole thing currently, but if this is generally what you are looking for we may contribute this kind of acl pretty soon... regards, david
