jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <mreut...@adobe.com>
Subject RE: NodeStates and security (Re: svn commit: r1458234 - in /jackrabbit/oak/trunk: oak-core/src/main/java/org/apache/jackrabbit/oak/core/ oak-core/src/main/java/org/apache/jackrabbit/oak/kernel/ oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/v...
Date Thu, 21 Mar 2013 14:34:53 GMT
OK, thanks. This clarifies things quite a bit.

regards
 marcel

> On Thu, Mar 21, 2013 at 3:02 PM, Marcel Reutegger
> <mreutegg@adobe.com> wrote:
> > Do we really understand well enough what the consequences
> > are moving permission evaluation even further down? I.e.
> > *below* the NodeState API?
> 
> That's where I originally envisioned it to be taking place, as a
> mostly transparent wrapper around the underlying storage layer (*).
> 
> Of course back when we were originally designing NodeState, we didn't
> fully realize the impact of the "invisible parent" scenario (which
> Angela was right to point out), which then led to the TreeLocation
> concept and related machinery above the NodeState level. The way I see
> it, with better design and encapsulation we should be able to get rid
> of most of that stuff.
> 
> Of course the full consequences of a change like what's being
> discussed aren't yet thoroughly understood (for example the impacts on
> node builders, content diffs, the TreeLocation interface, etc. are yet
> to be considered). That's why we're discussing. :-)
> 
> *) Instead of a full wrapper, such a "secure NodeState" would/should
> only be applied as the basis of TreeImpls visible to the client.
> Things like CommitHooks or the search engine would still work directly
> against NodeStates coming from the storage layer.
> 
> BR,
> 
> Jukka Zitting

Mime
View raw message