jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject TreeImpl vs ReadOnlyTree
Date Thu, 19 Jul 2012 08:40:17 GMT
hi all

while working on a initial permission check upon read access in
oak i found that there are two implementations of the Tree interface:

- TreeImpl:
   > only used within RootImpl
   > package private create method, private constructor

- ReadOnlyTree:
   > used in NameValidatorProvider and NamespaceValidatorProvider
   > public constructore taking a NodeState

as far as TreeImpl is concerned it looks perfectly fine to add the
permission checks in the appropriated places as that information
is exposed to API comsumers such as e.g. oak-jcr.

however, i am not totally sure about the aim and goal of the
ReadOnlyTree and unfortunately there is no javadoc explaining the
expected usage/exposure.

the current usages in the validator providers and the constructor
taking a NodeState gave me the impression that this implementation
is expected to be rather used for system internal evaluation where
enforcing access control for the editing content session may in fact
prevent that task: the mentioned validators for example access
namespace information stored underneath /jcr:system that may or may
not be accessible to a given content session.

so:
- what is the aim of the ReadOnlyTree?
- is my assumption correct or would it be required to enforce access
   restrictions on the ReadOnlyTree as well?
- if the ReadOnlyTree is meant to be an 'internal' implementation of
   the Tree interface, can we really enforce that it cannot be abused?
- i quickly checked if the NodeState interface was really just used
   within oak-core and not exposed: however i found that there as least
   one reference to the NodeState interface in oak-jcr (observation).

kind regards
angela

Mime
View raw message