[
https://issues.apache.org/jira/browse/OAK-4611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15395816#comment-15395816
]
Chetan Mehrotra commented on OAK-4611:
--------------------------------------
h3. Using Mount information to manage storing and reading content in
multiplexing setup
In normal setup all paths are part of "default" mount. In multiplexing setup
certain parts of the tree may be part of other mounts.
*
[Mount|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/mount/Mount.java]
*
[MountInfoProvider|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/spi/mount/MountInfoProvider.java]
- A MountInfoProvider instance would always be present in any setup. By
default it would have single mount i.e. default mount.
Lets taken an example of below setup
{noformat}
private
- /libs
- /apps
default
- /
{noformat}
In above setup nodes under /apps and /libs (include apps and libs) are part of
"private" mount (mount name is "private"). While all other paths are part of
default mount. Now lets see how mount information is used to manage storage in
permission store. In a default setup permission store has following structure
{noformat}
/jcr:system/rep:permissionStore
+ default //workspace name
+ editor //principal name
+ 1227964008 (rep:PermissionStore) //path hash
- rep:accessControlledPath = /content
+ 0
- rep:isAllow = true
- rep:privileges = [1279]
+ 1345610890 (rep:PermissionStore) //path hash
- rep:accessControlledPath = /libs
+ 0
- rep:isAllow = false
- rep:privileges = [1279]
{noformat}
In above setup permissions for principal 'editor' for various paths are stored
as child nodes under '/jcr:system/rep:permissionStore/default/editor'. In a
multiplexing setup the structure would get modified for those paths which are
not part of default mount
{noformat}
/jcr:system/rep:permissionStore
+ oak:mount-private
+ default
+ editor
+ 1345610890 (rep:PermissionStore) //path hash
- rep:accessControlledPath = /libs
+ 0
- rep:isAllow = false
- rep:privileges = [1279]
+ default //workspace name
+ editor //principal name
+ 1227964008 (rep:PermissionStore) //path hash
- rep:accessControlledPath = /content
+ 0
- rep:isAllow = true
- rep:privileges = [1279]
{noformat}
In a multiplexing setup we create new buckets under
'/jcr:system/rep:permissionStore' based on Mount name and then use that as root
for storing permission related data for paths belonging to paths under those
mounts.
h4. Writing side changes
On commit side when PermissionHook needs to add entries to permission store it
would do something like below
{code}
MountInfoProvider mountInfoProvider = ...
String getStoragePath(String path){
Mount m = mountInfoProvider.getMountByPath(path);
if (m.isDefault()){
return defaultPermissionRoot;
}
String mountFragment = m.getPathFragmentName();
return '/jcr:system/rep:permissionStore/' + mountFragment + '/default'
}
{code}
Here 'oak:mount-private' is mountFragment as returned by
Mount#getPathFragmentName() call
When such a node structure is saved the NodeStore implementation would look for
such path fragment and then would store nodes under such paths to the
persistent store meant to store paths belonging to 'private' mount
h4. Reading Side Changes
In the reading side where authorization logic needs to look for permissions
assigned to principal 'editor' for specific path the code flow would also need
to be adapted to account for multiplexing. Currently a {{PermissionStore}}
loads permission based on single permission root. In multiplexing setup it
would be changed to make use of {{MultiplexingPermissionStore}}.
This can be done in 2 ways
# Looks for all immediate nodes under '/jcr:system/rep:permissionStore' and see
if they confirm to permission root pattern i.e. there name is either 'default'
or of form like 'oak:mount-<>-default'. Then construct permission store based
on those node as permission root. Then each call to permission store would
result in sum of results from permission store created for those permission
roots
# Look for all Mounts defined in {{MountInfoProvider}} and then derive the
permission root paths via Mount#getPathFragmentName() and then construct
permission store instances with those nodes as permission store root
See
[d6a3d262393a98f30|https://github.com/chetanmeh/jackrabbit-oak/commit/d6a3d262393a98f307b011b09474871c3199c660]
which takes #2 approach mentioned above
> Document Multiplexing Support for PermissionProvider
> -----------------------------------------------------
>
> Key: OAK-4611
> URL: https://issues.apache.org/jira/browse/OAK-4611
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: doc
> Reporter: angela
> Assignee: Chetan Mehrotra
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
