jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.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:13:02 GMT
Hi,

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