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 2018/12/04 07:51:00 UTC

[jira] [Commented] (OAK-7937) Implement CugAccessControlManager.getEffectivePolicies(Set principals)

    [ https://issues.apache.org/jira/browse/OAK-7937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16708325#comment-16708325 ] 

angela commented on OAK-7937:
-----------------------------

on a second thought: we might even decide not to cover the _everyone_ case at all... after all the method is considered to be best-effort only and it might not be sensible to just return every single cug-policy. after all there is {{AccessControlManager.getEffectivePolicies(String path)}}.

> Implement CugAccessControlManager.getEffectivePolicies(Set<Principal> principals)
> ---------------------------------------------------------------------------------
>
>                 Key: OAK-7937
>                 URL: https://issues.apache.org/jira/browse/OAK-7937
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>            Reporter: angela
>            Priority: Major
>             Fix For: 1.10
>
>
> today CugAccessControlManager.getEffectivePolicies(Set<Principal> principals) returns an empty array and has a comment stating that this is not implemented.
> having thought this through again, i think there was some benefit in having the implementation. as long as the given set of principal does NOT include everyone the return value should just include the CUG-policies that explicitly list any of principals. IF _everyone_  was part of the set, the return-value basically includes _all_ CUG-policies, because every CUG will deny read-access for everyone except for the principals explicitly listed in the CUG-policy... if we do the latter as lazy as possible it might still be doable even in a scenario, when there are tons of CUG-policies specified.
> [~stillalex], wdyt? do you want to take care of this?



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)