How to Master Entity Access in Drupal
Most Drupal devs are familiar with
hook_entity_access(and its cousins
hook_node_access). However, it is mostly used for serving “403: Access denied” to browsers. And we use a separate hook,
hook_form_alter to disable edit buttons on admin pages like content overview pages, node form edit and taxonomy form edit:
It would be more beneficial to use
hook_entity_access to disable access to the buttons. Disabling view, edit or delete (where applicable) via
hook_entity_access will handle the following all at once.
Advantages of using
1. Serve 403 pages
As mentioned above, this is the typical use for
hook_entity_acess. Users will be served 403 if access denied is returned by the hook.
2. All views listing page with entity operations
All views entity operations are already handled. This is the most significant benefit, as you don’t have to
hook_form_alter each of the listing pages in your site. By default, it will respect
3. Core Node Form / Taxonomy Form (Any default entity form)
The entity form delete button respects hook_entity_access, as is shown by the following image that depicts the delete button in the Drupal node admin interface.
4. Tabs / Local Tasks
The default core edit/delete tabs also respect hook_entity_access, as is shown by the following image depicting the admin tabs available for editors.
hook_entity_access. So in code, a deny in
hook_entity_access ‘view’ operation will also result in a deny in
At the heart of what we have talked about above relies on this behavior. All items above internally execute
Caveats on using
1. Allow / Deny rules
If at least one module issues a deny, then it will result in access denial, even if your module provides an allow access (other modules should only set a neutral access so that it does not inadvertently deny access to the entity).
At least one module must provide an allow access to an entity in order to provide access. If all modules give a neutral response, then it will result in an access denial.
$entity->access also respects the node permissions page (for node entities) in conjunction with
In the Permissions (/admin/people/permissions) page, you can set whether a certain role has access to edit, delete (own/any) content type. Internally, this also provides an access result allow when enabled, and the same Allow/Deny rules above apply.
This must be taken into consideration when combining
hook_entity_access with permissions page. So even if you issue a neutral access, you might wonder why something is still giving access. This might be given through the permission pages.
3. Other operations
By default, Drupal core provides ‘view’, ‘update’, ‘delete’, ‘create’ access. And you can further filter the access via operation type. Internally, this translates to
Modules like content translation provide other entity operations apart from the basic ones above. In particular, content_translation core provides a ‘translate’ operation. In your
hook_entity_access. You can then expect a value of ‘translate’ on $operation, when for example, rendering the translate button on the pages described above.
You can find
hook_entity_operation[_alter] in order to define/alter entity operations.
Additionally, the other operations might intentionally depend on the ‘view’ operation, etc. In particular, content_translation module also depends on the ‘view’ operation in showing the translate button. Denying access on view operations will also deny access to the translate button. So special conditions must be added for such instances.
4. Caching permissions
Be sure to set proper caching to AccessResult returned by
In this example,
$entity was added as a caching dependency to AccessResult and also the current theme used.
Looking for Drupal consultation and support for your complex website development? Contact us today.