Different Permissions on the Same Node
Multiple roles can have different permissions on the same node. Some interactions between roles may be unexpected. For example, if you have a document with two nodes <foo>
and <bar>
. The <bar>
node is a child of the <foo>
node.
<foo> <bar>
You have two roles; role1
with both read
and update
permissions on the <foo>
node, and role2
with read permissions on the <bar>
node:
<foo>, ("role1", "read"), ("role1", "node-update") <bar>, ("role2", "read")
Note
At the element level, the update
and node-update
functions are equivalent.
The protected paths for this document would look like this:
sec:protect-path("//foo", (), ( xdmp:permission("els-role-1", "read"),("role1", "node-update")) sec:protect-path("//foo/bar", (), ( xdmp:permission("role2", "read"))
With these protected paths, role1
cannot read the <bar>
node. But because role1
has update permissions on the parent node (<foo>
), role1
can overwrite the <bar>
node, even though it cannot read it.
To prevent this, add node-update permissions to the <bar>
node. The permissions would now look like this:
<foo>, ("role1", "read"), ("role1", "node-update") <bar>, ("role2", "read"), ("role2", "node-update")
The presence of the “node-update” permission on the <bar>
node prevents role1
from being able to update and overwrite the <bar>
node (the child node of the <foo>
node).
This happens because node permissions are checked separately; first there’s a check for protected paths for read
. Then there is a check for protected paths for update
. If no update is found for /foo/bar
, then role1
is allowed to update <bar>
. If there is a protected path for updating <bar>
, then role1
is not allowed to update <bar>
.