You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Konrad Windszus (JIRA)" <ji...@apache.org> on 2015/01/26 09:59:34 UTC

[jira] [Commented] (OAK-2441) Regression with Node.getPrimaryNodeType and getMixinNodeTypes wrt Jackrabbit 2.x

    [ 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)