[ 
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

Reply via email to