hi, On Mon, Jul 26, 2010 at 1:12 PM, Ard Schrijvers <[email protected]> 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 >
