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 2017/06/02 08:52:04 UTC

[jira] [Comment Edited] (OAK-4612) Multiplexing support for CugPermissionProvider

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

angela edited comment on OAK-4612 at 6/2/17 8:51 AM:
-----------------------------------------------------

[~alex.parvulescu], initial draft to get the discussion started at https://github.com/anchela/jackrabbit-oak/commit/bd2d03d8647ca7466988ad7ec731a56206b78528. In particular I wasn't totally sure I got the Mount API right (javadoc is a bit sparse) when it comes to verifying if a given supported path in the CUG authorization model would conflict with mounts (both supported being located inside a mount and a mount being contained in the set of supported paths, which both should not be possible for the reasons above).

apart from tests the patch primarily changes the way the supported paths are calculated taking the {{MountInfoProvider}} into account. This now done only once in {{CugConfiguration}} and remembered there right away in order to avoid potentially expensive calculation whenever it is called. those (adjusted) supported paths are passed both to the {{AccessControlManager}} as well as the {{PermissionProvider}}.

TODOs:
- -make sure changes to {{MountInfoProvider}} are reflected in the cug authorization-
- -verify {{TreePermission}} impls and {{NestedCugHook}} work properly with {{Mount}} (s)- (not needed as closed user groups will never be evaluated on a non-default mount as supported paths are only allowed if there is no collision with mounts).
- tests with mount points (https://github.com/anchela/jackrabbit-oak/commit/1551962676465cea9b7964ff675755ee3d8173e1) (/)
- -performance (if the proposed solution proves to work, I don't see any reason for performance impact as the performance relevant code doesn't change... but verifying that can't be wrong).- checked again and really didn't see any reason why the current impl would have an impact on performance.


was (Author: anchela):
[~alex.parvulescu], initial draft to get the discussion started at https://github.com/anchela/jackrabbit-oak/commit/bd2d03d8647ca7466988ad7ec731a56206b78528. In particular I wasn't totally sure I got the Mount API right (javadoc is a bit sparse) when it comes to verifying if a given supported path in the CUG authorization model would conflict with mounts (both supported being located inside a mount and a mount being contained in the set of supported paths, which both should not be possible for the reasons above).

apart from tests the patch primarily changes the way the supported paths are calculated taking the {{MountInfoProvider}} into account. This now done only once in {{CugConfiguration}} and remembered there right away in order to avoid potentially expensive calculation whenever it is called. those (adjusted) supported paths are passed both to the {{AccessControlManager}} as well as the {{PermissionProvider}}.

TODOs:
- -make sure changes to {{MountInfoProvider}} are reflected in the cug authorization-
- -verify {{TreePermission}} impls and {{NestedCugHook}} work properly with {{Mount}} (s)- (not needed as closed user groups will never be evaluated on a non-default mount as supported paths are only allowed if there is no collision with mounts).
- tests with mount points (https://github.com/anchela/jackrabbit-oak/commit/1551962676465cea9b7964ff675755ee3d8173e1) (/)
- performance (if the proposed solution proves to work, I don't see any reason for performance impact as the performance relevant code doesn't change... but verifying that can't be wrong).

> Multiplexing support for CugPermissionProvider
> ----------------------------------------------
>
>                 Key: OAK-4612
>                 URL: https://issues.apache.org/jira/browse/OAK-4612
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: authorization-cug
>            Reporter: angela
>            Assignee: angela
>             Fix For: 1.8, 1.7.1
>
>
> as discussed we will use the {{CugPermissionProvider}} to validate the proposal against another (quite different) implementation.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)