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
angela
On 4/24/13 3:23 PM, Jukka Zitting wrote:
Hi,
On Wed, Apr 24, 2013 at 3:59 PM, Angela Schreiber<[email protected]> 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
