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
