| Table of Contents |
|---|
Overview
In order to enforce policies, your PEP must figure out what to do when asked for certain permissions. In some cases more than one permission is requested of the PEP in order to complete to overall ModeShape operation. In addition, some Fedora operations, such as object creation, involve several ModeShape operations. All of the ModeShape operations that compose a Fedora API call are performed in a single session with one save point and will succeed or fail together.
ModeShape Actions
Permission checks often rely on the retrieval of metadata about existing nodes.
Newly created nodes and newly set properties are only effective once the session is saved.
Repository changes, such as new role assignments, that are being made in an unsaved session are not effective for permission checks, which do not have access to unsaved sessions.
ModeShape Actions
| action | context | action | path | notes |
|---|---|---|---|---|
add_node | full path to the new node | |||
| set_property | full path to the property | |||
| read | path to the node | |||
| remove | path to the node | |||
| remove_child_nodes | path to parent node |
...
Cascading Permissions and Removing Sub-Trees
An attempt to remove a node will trigger a call with the remove action on the subject node and call with the remove_child_nodes action on the parent node. Both must return true for the operation to proceed. Roles that are set in an unsaved session are not effective, even within that session.If your PEP needs to enforce deletes in a cascading fashion, as when using access roles, then the "remove" action must include the permissions check of remove on descendant nodes. (See AbstractRoleBasedPEP for an example)