Drupal 7 Module Development

Chapter 9
The Node Access API allows modules to alter how the default Drupal CRUD
workflow behaves. Normally, Drupal nodes are created by a single user. That user
"owns" the node and, in most cases, may edit or delete the node at will. Some users,
like the administrative user 1, may edit any node. But by default, Drupal has no
concept of group ownership of nodes. Certain roles may be given permission to edit
all nodes of a type (as shown by the core edit any Article content permission,
for instance), but out of the box there is no provision for restricting access to view
that content.
The Node Access API evolved out of the need to define a flexible, extensible set of
access rules. Much has improved in Drupal 7, so experienced developers will want
to review this material carefully.
Node Access permissions are checked in two instances:
• When requests to act upon an individual node are made.
• When database queries return lists of nodes that match given conditions.
In order to handle node access securely, module developers need to be mindful of
both cases.
The first case is fairly simple, and is generally handled by a menu callback and the
node_access() function. Unless your module intends to interfere with the normal
handling of node_menu(), you may be able to skip the rest of this chapter.
However, all module developers need to understand the impact of case two. Let's
highlight it here.
Any database query involving the {node} table must be built
dynamically and be marked as a node access query. Failure to
do so can introduce security vulnerabilities on sites running
your code.
To understand this rule, let's look at a simple example from Drupal core. The
following query is found in node_page_default(), the function that provides the
basic node listing page:
$select = db_select('node', 'n')
->fields('n', array('nid'))
->condition('promote', 1)
->condition('status', 1)
->orderBy('sticky', 'DESC')
->orderBy('created', 'DESC')
->extend('PagerDefault')
[ 243 ]