Ryan Dewell wrote:
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. 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.
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...
fwiw - what you're talking about is exactly what i've done. i create user home directories as nt:folder nodes just below the root node.
i have a custom AccessManager that implements rudimentary home directory owner permissions. in my app, that means the principal's name is the same as the display name of the home directory node.
i ran into a situation as well where the AMContext didn't give me enough info. jackrabbit checks permissions on the version storage node (/jcr:system/jcr:versionStorage) when creating a node. AMContext doesn't have enough info for me to look up the node that's related to the version history being created so that i can do owner permission checks on it. not the same as your situation, but also shows that we're probably looking to do things with AccessManager that folks didn't originally envision :)
fwiw, i've implemented my security layer with Acegi Security, so my AccessManager doesn't care where the permission info is stored. it just checks the Subject for a principal that has all the security info already loaded (my app does that in a servlet filter prior to accessing the repository).
