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 "angela (JIRA)" <ji...@apache.org> on 2015/01/22 16:30:35 UTC

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

angela created OAK-2441:
---------------------------

             Summary: 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


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)