jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tobias.bocane...@day.com>
Subject Re: Shareable nodes and access control
Date Tue, 27 Jul 2010 21:01:03 GMT

On Mon, Jul 26, 2010 at 1:12 PM, Ard Schrijvers
<a.schrijvers@onehippo.com> wrote:
> Hello,
> From the spec jsr-283 I cannot get my head around one thing:
> * What is the expected behaviour of modifying child nodes of shared
> nodes, when you are not allowed to read the child nodes of one of the
> shared nodes (because of some access path constraint for example).
i'm not sure how exactly it is implemented currently, but for resource
based access control, i think that only the primary ancestors inherit
the ACLs.
so the ACL of a shared set is the one of the primary node. for user
centric access control, it's of course path based.

regards, toby

> Another thing that I am curious about, though I have to look into the
> code still, is how searching for shareable nodes with path constraints
> & access work out.
>  I assume it should work as:
> 1) Without path constraints, searches return me the 'principal'
> location of shareable nodes.
> 2) With path constraints, I assume a hit is returned that matches the
> path constraint, and thus might be not the 'principal' location
> 3) With access, and this is the tricky one as this is *not* known
> during Lucene query time, it should return me a node that might be not
> the 'principal' one because of I am not allowed to access the
> principal one (how does this relate to the hit collapsing, which I
> assume already happens during Lucene query for performance reasons)
> Well, I admit I still have to dive into the code, but I was just
> wondering how these case should be handled in general
> thx for any feedback
> Regards Ard

View raw message