Drupal 7 Module Development

Chapter 8
}
$permissions = array(
'access user profiles',
'administer users',
);
$role = user_role_load_by_name('acount moderator');
user_role_grant_permissions($role->rid, $permissions);
When our module is uninstalled, we should delete the role as well.
function account_moderator_uninstall() {
user_role_delete('account moderator');
}
Securing forms in Drupal
Form handling is one of the most crucial areas of website security. Inappropriate
handling of form data can lead to multiple security weaknesses including SQL
injection and cross-site request forgeries (CSRF). While we cannot cover all aspects
of security in a brief chapter, it is important to state some clear guidelines for Drupal
module developers.
See http://en.wikipedia.org/wiki/CSRF for information on
CSFR, and for cross-site scripting (XSS) see http://en.wikipedia.
org/wiki/XSS.
The Forms API
First and foremost, you should always use the Drupal Forms API when creating and
processing forms in Drupal. For one, doing so makes your life easier because the
Forms API contains standards for form definition, AJAX handling, required elements,
validation handling, and submit handling. (See more about forms in Chapter 5.)
From a security standpoint, the Forms API is critical because it contains built-in
mechanisms for preventing CSRF requests.
Whenever Drupal creates a form through the API, the form is tagged with a
unique token called the form_build_id. The form_build_id is a random
md5 hash used to identify the form during processing. This token is added
by the drupal_build_form() routine:
$form_build_id = 'form-' . drupal_hash_base64(uniqid(mt_rand(), TRUE)
. mt_rand());
$form['#build_id'] = $form_build_id;
[ 229 ]