jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Duck typing in Oak
Date Thu, 25 Apr 2013 09:34:12 GMT
hi jukka

i don't see how you would enforce that in the nt validation
without making moving access control specific implementation
logic (which needs to be pluggable) into the nt plugin, which
IMO was not the right thing to do...

from a pure node type point of view it was legal to create
a node named "rep:policy" underneath a nt:unstructured node.
similarly an nt:unstructured node would allow you to create
a child of type "rep:ACL"... it's just the JCR specific
protection that will not allow you to create an ACE below.
with oak it would work as as we found that we can't and
don't want to enforce the protected flag associated with
nodes and properties on the oak level.

kind regards

On 4/24/13 3:23 PM, Jukka Zitting wrote:
> Hi,
> On Wed, Apr 24, 2013 at 3:59 PM, Angela Schreiber<anchela@adobe.com>  wrote:
>> as far as access control content is concerned that validation
>> is IMO required due to the fact that without the mixin type
>> on the parent the policy nodes would have a different declaring
>> node type which IMO is part of the contract defined by the
>> implementation... e.g. the repo could contain rep:policy nodes
>> that are basically invalid.
> I'm proposing that we move the checking of such constraints to the
> type validator where we already have all relevant type information
> readily available and where we can more easily optimize the constraint
> checking.
> Note that doing so would require us to extend the type validator with
> some extra rules, like that content in reserved namespaces like
> rep/internal can only occur when there's a built-in node type with a
> matching named item definition. Such a rule would for example
> guarantee that a rep:policy node can only occur when the parent is
> rep:AccessControllable. Then there would be no need for the access
> control validator to re-check that constraint and it could simply
> treat all rep:policy nodes as containers of access control
> information.
>> while taking a closer look at the permission evaluation i found
>> that the commit hooks and validators get informed about all
>> index updates which then get explicitly ignored by most
>> validators/hooks, except for those dealing with index update.
> The best way to address this is to move the index updates to be
> performed only after all the other hooks/editors have been processed.
> Unfortunately this doesn't cover all possible cases (like when an
> entire subtree is copied around together with the contained hidden
> content), so an additional piece of functionality, described below, is
> needed.
>> wouldn't it be possible to make it an explicit characteristic
>> of the commit hooks if they want/need to deal with hidden
>> trees and/or properties? IMO that would simplify the wast
>> majority of all hooks and significantly reduce the amount of
>> calls.
> Indeed. The o.a.j.o.spi.commit.VisibleEditor wrapper class that's
> explicitly designed for this purpose. The provider of an editor (which
> is what most of our commit hooks would ideally become), that doesn't
> need to care about hidden content, can use a VisibleEditor wrapper for
> the root editor it returns to prevent any hidden content from showing
> up to that editor. See the TypeEditorProvider class for an example of
> that feature in action.
> BR,
> Jukka Zitting

View raw message