The node access system determines who can do what to which nodes.
In determining access rights for a node, node_access() first checks whether the user has the "bypass node access" permission. Such users have unrestricted access to all nodes. user 1 will always pass this check.
Next, all implementations of hook_node_access() will be called. Each implementation may explicitly allow, explicitly deny, or ignore the access request. If at least one module says to deny the request, it will be rejected. If no modules deny the request and at least one says to allow it, the request will be permitted.
If all modules ignore the access request, then the node_access table is used to determine access. All node access modules are queried using hook_node_grants() to assemble a list of "grant IDs" for the user. This list is compared against the table. If any row contains the node ID in question (or 0, which stands for "all nodes"), one of the grant IDs returned, and a value of TRUE for the operation in question, then access is granted. Note that this table is a list of grants; any matching row is sufficient to grant access to the node.
In node listings (lists of nodes generated from a select query, such as the default home page at path 'node', an RSS feed, a recent content block, etc.), the process above is followed except that hook_node_access() is not called on each node for performance reasons and for proper functioning of the pager system. When adding a node listing to your module, be sure to use a dynamic query created by db_select() and add a tag of "node_access". This will allow modules dealing with node access to ensure only nodes to which the user has access are retrieved, through the use of hook_query_TAG_alter(). Tagging a query with "node_access" does not check the published/unpublished status of nodes, so the base query is responsible for ensuring that unpublished nodes are not displayed to inappropriate users.
Note: Even a single module returning NODE_ACCESS_DENY from hook_node_access() will block access to the node. Therefore, implementers should take care to not deny access unless they really intend to. Unless a module wishes to actively deny access it should return NODE_ACCESS_IGNORE (or return nothing) to allow other modules or the node_access table to control access.
To see how to write a node access module of your own, see node_access_example.module.
modules/ node/ node.module, line 2567
- The core module that allows content to be submitted to the site.
||Controls access to a node.|
||Set permissions for a node to be written to the database.|
||Alter permissions for a node before it is written to the database.|
||Inform the node access system what permissions the user has.|
||Alter user access rules when trying to view, edit or delete a node.|
||Access callback: Checks a user's permission for performing a node operation.|
||Gets the list of node access grants and writes them to the database.|
||Fetches an array of permission IDs granted to the given user ID.|
||Toggles or reads the value of a flag for rebuilding the node access grants.|
||Rebuilds the node access database.|
||Determines whether the user has a global viewing grant for all nodes.|
||Helper function to generate standard node permission list for a given type.|
||Returns an array of node types that should be managed by permissions.|
||Performs post-processing for node_access_rebuild().|
||Performs batch operation for node_access_rebuild().|
||Writes a list of grants to the database, deleting any previously saved ones.|
||Helper for node access functions.|
||Exclude nodes from the search query where the node has a hidden path and the current user doesn't have permission to bypass the restriction.|