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 "Jukka Zitting (JIRA)" <ji...@apache.org> on 2013/04/03 17:49:15 UTC

[jira] [Updated] (OAK-709) Consider moving permission evaluation to the node state level

     [ https://issues.apache.org/jira/browse/OAK-709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jukka Zitting updated OAK-709:
------------------------------

    Attachment: SecureNodeState.java

See the attached {{SecureNodeState}} class for a quick draft of how I'd see this being implemented. The security checks would go into the {{canReadThisNode}} and {{canReadEverythingInThisSubtree}} methods (plus {{canReadProperty}} if needed). Since node states are immutable, these checks could be computed during {{SecureNodeState}} construction or their results could be memorized when first accessed to avoid duplicate work.

bq. we don't have the hierarchy information on the nodestate

The {{SecureNodeState}} wrapper as outlined can keep track of the hierarchy information (and any other details it needs) even if that information is not included in the raw node states that come from the underlying storage.

bq. what about the cache we are currently having on the nodestate level

We'd still keep it as-is. The {{SecureNodeState}} instances can additionally be cached using {{(Set<Principal>, NodeState)}} pairs as a key.

With this combination we can cache raw content across sessions and access control checks separately for each set of principals.

bq. the permission provider is not only used on the oak-core level but also in oak-jcr for the permission related jcr calls and within the access control mgt which both don't have access to the NodeState API.

A few initial ideas on how we could do this:

* Make both the {{SecureNodeState}} class and the higher level components use the same permission provider mechanism (with thing like ReadOnlyTree to bridge the API gap).
* Use the raw content (in the permission store) as the shared "API" between the low-level {{SecureNodeState}} class and the higher-level components. Each would read and interpret that data directly, a bit like I'm now doing with the node type information.
* Extend the Oak API to cover the required security features.

                
> 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, 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