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 16:42:19 GMT
Hi David,

Although I wasn't able to access the Content Explorer as jane or bob (I 
received an internal server error), I did browse around with the admin user 
and took a look at your node types for accessControl, etc, as well as the 
folders you'd set up for bob and jane.  To put it bluntly: that's exactly 
what I was trying to describe!  Of course your gorgeous console makes this 
easier to visualize.

I don't really have anything to add.  As far as I can tell, your design 
pretty much covers everything I was imagining.  I think this early on in my 
project I'll move forward with the "one workspace" notion knowing that I'm 
going to either need to implement some similar security down the road, or 
will find that jackrabbit's built-in security as evolved a bit more in the 

Thanks for your help!


"David Nuescheler" <david.nuescheler@gmail.com> wrote in message 
> 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

View raw message