[
https://issues.apache.org/jira/browse/OAK-709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13627658#comment-13627658
]
angela commented on OAK-709:
----------------------------
michael and myself just hand a quick chat around this topic:
another possibility would be to change the NodeBuilder such that it can
recalcuate the pending changes against a provider NodeState (which in our
case was the non-secure base).
the benefit was:
- RootImpl#getRootState could again be the non-secured root state is it was
before
- RootImpl#purgePendingChanges would compare the non-secured base against the
non-secured head
- no extra hack in RootImpl, PurgeRebaseDiff was superfluous
- special cases such as 'add new item' that exists but is not
accessible/writable to
the editing session would naturally be handled by the existing validators
(modifying property throws
accessdenied, add node would be detected by the type validator).
[~mduerig], please correct my if that doesn't fully summarize our discussion.
> 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
