Drupal 7 Module Development

Chapter 9
Security considerations
The above code works just fine. But there is a potentially dangerous flaw in its logic:
we do not account for variations of the different operations. As written, the module
gives View, Update, and Delete access to all nodes based on user role. This could be
a huge problem if we don't want some roles to delete content.
One way to correct this issue is to leverage the core permission system to establish
additional rules that our module implements. We can assign specific permissions
to allow each role access to the various operations.
If you recall Chapter 8, Drupal Permissions and Security, implementing
hook_permission() gives us an easy way to do this.
/**
* Implement hook_permission().
*
* Define our modules permissions as follows:
* -- view role access content
* -- update role access content
* -- delete role access content
*
* Naming these properly helps avoid conflicts with other modules.
* Note that we name these based on the $op value passed by
* hook_node_grants(). This allows us to use string concatenation
* when doing our access check.
*/
function role_access_permission() {
return array(
'view role access content' => array(
'title' => t('View role-restricted content'),
'description' => t('Allow users to view content assigned by
role.'),
),
'update role access content' => array(
'title' => t('Edit role-restricted content'),
'description' => t('Allow users to edit content assigned by
role.'),
),
'delete role access content' => array(
'title' => t('Delete role-restricted content'),
'description' => t('Allow users to delete content assigned by
role.'),
),
);
}
[ 271 ]