[
https://issues.apache.org/jira/browse/OAK-2441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14291591#comment-14291591
]
Konrad Windszus commented on OAK-2441:
--------------------------------------
Since this issue might be breaking compatibility with Jackrabbit 2, could we
backport that also to Oak 1.0.x?
Also are there any plans to distinguish access rules to nodes and properties?
> Regression with Node.getPrimaryNodeType and getMixinNodeTypes wrt Jackrabbit
> 2.x
> --------------------------------------------------------------------------------
>
> Key: OAK-2441
> URL: https://issues.apache.org/jira/browse/OAK-2441
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Reporter: angela
> Assignee: angela
> Fix For: 1.1.6
>
>
> while trying to reproduce OAK-2412 i found that {{Node.getPrimaryType}} and
> {{Node.getMixinNodeTypes}} behave differently wrt Jackrabbit 2.x if the
> underlying JCR property is not accessible to the editing session.
> While Jackrabbit 2.x directly reads the type information from the non-secured
> NodeState and only enforces a permission evaluation if the corresponding JCR
> properties are access, Oak obtains the type information through the JCR (or
> Oak API) which always secures the access to the underlying node state.
> From a security point of view the Oak behavior looks somehow more consistent
> to me, but one could also argue that reading meta information associated with
> an {{Node}} by the means of regular Node-API calls should be accessible if
> the node itself can be read by the editing session.
> From a backwards compatibility point of view, the Oak behavior is a clear
> break of compatibility which seems to cause issues with applications that
> relied to the Jackrabbit specific behavior.
> As long as the default implementation doesn't provide means to easily grant
> read-access to a Node and it's Properties, we should probably fix the
> regression.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
