Module Roundup: Content Access Control

Note: New contributed modules for Drupal are released all the time, while existing ones are updated with new features or become obsoleted by others. Our Module Roundup articles are a snapshot of the available solutions for a problem at the time the article is published.

What is content access control?

In this article, we'll be looking at ways of restricting access to the content of a site. Content takes many forms, including not just nodes but files, blocks, menu items, taxonomy terms, etc. Most of the solutions we will cover apply broadly to these scenarios, but examples will be focused on nodes because this is the most common scenario.

Access control can also apply to either viewing or editing content. Many Drupal sites have a small number of administrators and editors who can control most of the site, and a large number of visitors. As such, most of the access control solutions focus primarily on viewing access, and only the more sophisticated ones extend to controlling what pieces of content an editor can manipulate.

Out-of-the-box functionality

Drupal 8 allows site builders to control access to some degree. This is handled through three settings: The author of a node, the publication status of the node, and the permissions associated with the user's role.

Content will by default return an "access denied" message when a user attempts to view it, unless appropriate permissions are granted. A node can be viewed if:

• The node is published, and the user has the View published content permission
• The user has the Bypass content access control permission
• The user has the View own unpublished content permission, if the node's author

Editing restrictions are a bit more granular. A node can be edited if:

• The user has the Bypass content access control permission
• The user can Edit any content for this content type
• The user can Edit own content for this content type, and is the node's author

These permissions are limited, but do cover a lot of the most common scenarios. If you have a site that is entirely private to registered members, just turn off View published content for anonymous users. If you have a site that is entirely public, and edited by a select few who have their run of the place, give the editors the Edit any content permission for all content types.

Contributed modules

If you need more sophistication, you can install a contributed module or write your own. We won't cover custom modules here, but will run through some of the best contrib module options next.

Node View Permissions

If you don't have any special needs with regard to editing, and just need to limit access to a few pieces of content, Node View Permissions is about as lightweight as you can get. It simply adds permissions which are subdivided for viewing content by each content type individually.

This is a great solution if the kinds of content that need to be private naturally fall in line with specific kinds of fields. If a given type of content has some public and some private nodes in it, though, this would be a cumbersome approach as it would require unnecessary duplication of content types and related configuration.

Content Access

By using the Content Access module, you can limit either viewing or editing access to content by content type or on an individual node basis. Users with permission to grant access are given a new "Access control" tab on the content, which contains checkboxes for every role on the site and every permission: view all content of this type, view own content of this type, edit all content of this type, etc.

If the ACL module is additionally installed, then administrators will also be able to grant these permissions for individual users rather than roles. This allows for a lot of setup flexibility.

The primary downside to this module is that the interface is unwieldy, especially as the number of roles grows. It is a good fit for sites that need per-type or per-node customization of editing permissions, but have a limited number of technically-skilled administrators that will be responsible for keeping those permissions up to date.

Workbench Access

If you need a lot of flexibility with regard to editing but not viewing content, Workbench Access is a great candidate. This module does not touch view permissions at all. It lets you divide content into a hierarchical set of "editorial sections" of a site, and assign users to the same. Users can create and edit content only within their authorized sections.

Workbench Access is best suited for situations where all content is designed for public consumption, but the organization creating that content is large. It plays well with a moderation workflow.

Group

The Group module is the evolution of Organic Groups in Drupal 7. This is a Swiss army knife of a module, allowing for lots of use cases. Users belong to groups, as do nodes. Groups are entities in themselves, and can have their own sub-levels of permissions within them.

All of this power comes with corresponding complexity. Installing Group means installing a number of other dependencies, which in turn means more maintenance overhead. Configuration is more difficult to understand than the above approaches.

Group is probably the most versatile option for access management short of writing your own custom module, but due to its complexity, it is best suited for use cases that really need such flexibility, such as sites where users completely manage their own "communities" of users and content within the scope of the larger site.

Other modules

There are lots of other mechanisms for controlling node access. To see a more complete list, search drupal.org for content access modules.

When evaluating other options, one quick litmus test is to ensure that the module uses the Drupal content access system, rather than just checking for access at the time a node is viewed. Modules that simply check access won't play nicely with mixed listings of content where some is viewable and some is restricted. An example of this is View access per node.

A module that correctly uses the content access system will implement the full set of access hooks including hook_node_access_records() and hook_node_grants(). If a module implements just hook_node_access() by itself, be wary.

Conclusion

Content access control is complex, and when it goes wrong the risks are quite high: private content could be exposed to the public, or information could be edited by unauthorized users. Maximize site capabilities while minimizing risk by choosing the simplest solution that is sufficient for your site creation needs.