jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anuj Kumar <anujs...@gmail.com>
Subject Re: Access Control Management with JCR
Date Thu, 18 Aug 2011 15:54:44 GMT
On Thu, Aug 18, 2011 at 8:42 PM, Angela Schreiber <anchela@adobe.com> wrote:

> On 8/18/11 4:19 PM, Mark Herman wrote:
>> 1. I think that should work.  This approach is kind of a "everything open
>> unless I close it" mindset, where you may want to consider "everything is
>> closed unless I open it."  If myapp and blog need anonymous access for
>> some
>> reason you may want to restructure so the content folders don't need to be
>> under them.
Thanks Mark. So, I will try to restructure and may be get the private,
public and shared folders up at the root level and then have different app
content within them depending on the permissions. Also, on the same lines,
does it make sense to have a separate folder for each user under the
'private' folder to separate the content?

I am confused on what is the best way to manage user specific content. I
read about the clear indication of not to use workspaces for individual
users. Keeping that in mind, I would prefer to have a separate folder for
each user and give the control to the owner. By going with this approach the
number of folders will grow with the number of users and that may be huge. I
don't know about Jackrabbit's limitations but can you or anyone on this
mailing list suggest from one's experience?

>> 2. All permissions will only go down a hierarchy.  Changing the
>> permissions
>> on a child won't have any effect on the parent (except for the fact that
>> it's
>> child was changed).  Obviously changed to the parents security will be
>> inherited by the children.
> ... unless you explicitly stop the inheritance by specifying
> an extra restriction with that ACE that only matches the
> parent node. this is part of the jackrabbit-specific extension
> of the JCR access control API.
> Thanks Mark and Angela. This helps. Also, I am referring to-

>  3. I'm not too familiar but through trial and error it looks like you need
>> to
>> add jcr:nodeTypeManagement as well.  I guess choosing a primary node type
>> for
>> a new node counts as nodeTypeManagement.
> correct, Node.addNode(String) does not need the extra privilege
> but Node.addNode(String, String ntName) does.
> Thanks. Yes, this was the issue, jcr:all includes jcr:nodeTypeManagement
and that's why it worked with jcr:All but not with jcr:write

> regards
> angela

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message