Version 1.6 (checked in on 2010/06/28 at 20:42:08 by rfay)
This is an example illustrating how to restrict access to nodes based on the node access system. It implements an additional "private" marker for each node. The idea is that only the user (or specially permissioned users) can access a "private" node.
The node access system has three layers.
- Overall override permissions. User 1 and any user with 'bypass node access' permission are automatically granted access.
- hook_node_access() gives each module the opportunity to approve or deny access. Any module that returns NODE_ACCESS_DENY from hook_node_access() will result in denial of access. If no module denies access and one or more modules allow access, then access is granted.
- If no resolution has yet been reached, then the node_access table is used along with hook_node_grants().
In order to demonstrate hook_node_access() (see node_example_module_node_access()) to deny delete access to users with an even-numbered uid.
In addition, the traditional node rights system is employed to specify which users are allowed to view, edit, or delete "private" content.
This puts a single marker on a node: 'private'. The marker is implemented by a custom table which has one row per node simply indicating that the node is private. If the "private" marker is set, other users are denied access.
Additional standard permissions are defined which allow users with 'access any private content' or 'edit any private content' to override the node access restrictions.
Additionally, the node author can always view, edit, and delete the node. A separate access realm grants privileges to each node's author.
There are two basic building blocks in the node access system.
- hook_node_access_records() provides a list of "grants" for each node.
- hook_node_grants() provides determines which of those grants is available for a given user account.
Note that current best practice is probably to interoperate with the ACL module rather than directly implementing node access.
It's also critical to understand when working with node access rights that normally one would only use one module granting node access. That's the reason that ACL module has come to the fore, as it becomes the central clearing house for granting access. The problem with node acces is that it is a granting system, not a restricting system. As a result, the first module that grants access wins, even though some other node access module might have wanted not to grant access. So there's enormous (potential) ambiguity if one tries to use more than one node access module.
The only page provided by this module gives a rundown of how many nodes are marked private, and how many of those are accessible to the current user. This demonstrates the use of the 'node_access' tag in node queries, preventing disclosure of information which should not be shown to a user.
See: Node Access Rights and Handbook page on Node Access module
Functions & methods
| Name | Description |
|---|---|
| node_access_example_form_alter | Implements hook_form_alter(). |
| node_access_example_menu | Implements hook_menu() to provide a description. |
| node_access_example_node_access | Implements hook_node_access(). |
| node_access_example_node_access_records | Implements hook_node_access_records(). |
| node_access_example_node_delete | |
| node_access_example_node_grants | Implements hook_node_grants(). |
| node_access_example_node_insert | Implements hook_node_insert(). |
| node_access_example_node_load | |
| node_access_example_node_update | Implements hook_nodeapi_update(). |
| node_access_example_permission | Implements hook_permission(). |
| node_access_example_private_node_listing | Information for the user about what nodes are marked private on the system and which of those the user has access to. |
