[
https://issues.apache.org/jira/browse/OAK-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627983#comment-13627983
]
Michael Dürig commented on OAK-709:
-----------------------------------
bq. Correctly persisting such conflicting cases to the underlying branch would
likely require first removing the existing, read-protected content, which might
in turn make further SecureNodeState wrapping troublesome since accessible
parts in the subtree below such a node might become lost.
I think this depends on the intended behaviour for this case. Consider
{{/a/b/c}} being persisted and a session having full access to {{a}} and {{c}}
but no access to {{b}}. Such a session could transiently add a node {{b}}. What
should now be the effect of {{b.getNode("c")}}? And what for
{{session.getNode("/a/b/c")}}? IMO the best thing to do here is to "shadow" the
persisted {{b}} with the transient {{b}} meaning both calls would throw an
{{PathNotFoundException}}.
> Consider moving permission evaluation to the node state level
> -------------------------------------------------------------
>
> Key: OAK-709
> URL: https://issues.apache.org/jira/browse/OAK-709
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core
> Reporter: angela
> Attachments:
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch,
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch,
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch,
> 0001-OAK-709-Consider-moving-permission-evaluation-to-the.patch,
> OAK-709_2.patch, OAK-709_3.patch, OAK-709_4.patch, OAK-709-equals_hack.patch,
> OAK-709.patch, SecureNodeState.java
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
