[
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 2:04 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 to verify that the concept works for more implementations as well (or
even possibly refine the concept in case it was needed).
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 more implementations as well.
> 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)
