jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Moseley <...@osafoundation.org>
Subject Re: Workspaces
Date Mon, 11 Apr 2005 02:34:59 GMT
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).

View raw message