Drupal 7 Module Development

Drupal Permissions and Security
}
}
}
// as the empty string denotes the anonymous user. In case we
// are dealing with an anonymous user we set the user ID to 0.
form_set_error('name', t('The username %name does not exist.',
array('%name' => $node->name)));
// Validate the "authored on" field.
if (!empty($node->date) && strtotime($node->date) === FALSE) {
form_set_error('date', t('You have to specify a valid date.'));
}
// Do node-type-specific validation checks.
node_invoke($node, 'validate', $form);
module_invoke_all('node_validate', $node, $form);
The inclusion of this access check may add a level of error prevention—in that
users who cannot 'administer nodes' cannot alter the author without special
permissions—but it does not make Drupal itself more secure. That is because the
security for this form element is already set in the $form definition, so its usage
here is redundant:
// Node author information for administrators
$form['author'] = array(
'#type' => 'fieldset',
'#access' => user_access('administer nodes'),
'#title' => t('Authoring information'),
'#collapsible' => TRUE,
'#collapsed' => TRUE,
'#group' => 'additional_settings',
'#attached' => array(
'js' => array(drupal_get_path('module', 'node') . '/node.js'),
),
'#weight' => 90,
);
Instead, placing an access check in the validate handler forces a module author to
work around the code by replacing the core node_validate() and node_submit()
callbacks, which may introduce additional errors or security holes in the code.
For this reason, module authors are strongly discouraged from running access checks
during form processing.
[ 234 ]