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 "Chetan Mehrotra (JIRA)" <ji...@apache.org> on 2016/07/27 15:09:20 UTC

[jira] [Commented] (OAK-4611) Document Multiplexing Support for PermissionProvider

    [ 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)