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)