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 2016/07/14 13:27:20 UTC

[jira] [Comment Edited] (OAK-3777) Multiplexing support in default PermissionStore implementation

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

angela edited comment on OAK-3777 at 7/14/16 1:27 PM:
------------------------------------------------------

we just had a discussion about the multiplexing authorization models in a meeting. it turned out that I was mistaken about the fact that the physical location of the permission store entries associated with a secondary (private) store which according to the explanation of [~chetanm] is _not_ being written back to the shared (global) nodestore. instead the additional private store keeps it's own 'permission store' and it's only upon read and evaluation that a multiplexing aware permission-entry-reader needs to be aware of the multiplexing.

so, other authorization models (such as for example {{oak-authorization-cug}} can make a conscious decision on whether to support multiplexed setups by using and following the {{MountProvider}} API contract.

with that information at hand my concerns have been addressed and we decided on the following next steps:
- [~chetanm] will write the documentation on how to write multiplexing aware authorization modules
- I will then use that docu to adjust {{oak-authorization-cug}}, which will allow us the verify that the concept works for more implementations as well.


was (Author: anchela):
we just had a discussion about the multiplexing authorization models in a meeting. it turned out that I was mistaken about the fact that the physical location of the permission store entries associated with a secondary (private) store which according to the explanation of [~chetanm] is _not_ being written back to the shared (global) nodestore. instead the additional private store keeps it's own 'permission store' and it's only upon read and evaluation that a multiplexing aware permission-entry-reader needs to be aware of the multiplexing.

so, other authorization models (such as for example {{oak-authorization-cug}} can make a conscious decision on whether to support multiplexed setups by using and following the {{MountProvider}} API contract.

with that information at hand my concerns have been addressed and we decided on the following next steps:
- [~chetanm] will write the documentation on how to write multiplexing aware authorization modules
- I will then use that docu to adjust {{oak-authorization-cug}}, which will allow us the verify that the concept works for others

> Multiplexing support in default PermissionStore implementation
> --------------------------------------------------------------
>
>                 Key: OAK-3777
>                 URL: https://issues.apache.org/jira/browse/OAK-3777
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: core
>            Reporter: Chetan Mehrotra
>            Assignee: Chetan Mehrotra
>
> Similar to other parts we need to prototype support for multiplexing in default permission store



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)