jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Dewell" <r...@dewell.org>
Subject Re: Workspaces
Date Mon, 11 Apr 2005 04:06:00 GMT
Hi Brian,

Excellent information!  It is extremely helpful to hear how you implemented 
security for a similar situation, and also let's me know that I'm at least 
not missing anything huge.  :)


"Brian Moseley" <bcm@osafoundation.org> wrote in message 
> 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