Main Content
How to Master Hook Entity Access with Drupal

How to Master Entity Access in Drupal

Most Drupal devs are familiar with hook_entity_access(and its cousins hook_ENTITY_TYPE_ID_access and 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:


hook_form_alter vs. hook_entity_access


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.

Read Part II here.


Advantages of using hook_entity_access

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 hook_entity_access.

hook_entity_access default


default entity operations in views


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.


hook entity access


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.




5. $entity->access() checks

$entity->access(‘view|update|create|delete’) respects hook_entity_access. So in code, a deny in hook_entity_access ‘view’ operation will also result in a deny in $entity->access(‘view’).  

At the heart of what we have talked about above relies on this behavior.  All items above internally execute $entity->access() checks.


Caveats on using hook_entity_access:

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.


2. $entity->access also respects the node permissions page (for node entities) in conjunction with hook_entity_access()

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 $entity->access($operation).  

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.


caching based on theme and entity


4. Caching permissions

Be sure to set proper caching to AccessResult returned by hook_entity_access.  

In this example, $entity was added as a caching dependency to AccessResult and also the current theme used.


caching based on theme and entity


Looking for Drupal consultation and support for your complex website development? Contact us today.

Subscribe to Promet Insights