Drupal's API contains a pretty good description (Drupal 6, Drupal 7) of how node access works. Developers should also analyze the node_access function (Drupal 6, Drupal 7) itself. There are many contributed node access control modules for Drupal and you really should understand the basics of node access before installing and configuring one. The API should suffice for developers but for the benefit of our many community members who build sites without reading code, here is a translation and some basic rules of thumb (these rules were originally written for Drupal 6 - they have only been partially updated for Drupal 7):

• In general, you don't want to use more than one node access module on your site. There are many node access modules to choose from: taxonomy access, nodeaccess, simple access, workflow access, etc. We all tend to add lots of modules to our sites and to expect them to play well together, but node access is an area where we need to be extra thoughtful.

• Users with permission to 'administer nodes' (Drupal 6) or 'bypass node access' (Drupal7) are never restricted by node access modules. Users who do not have permission to 'access content' (Drupal 6) or 'view published content' (Drupal 7) will never gain access from a node access module. Only users who have 'access content'/'view published content' and not 'administer nodes'/'bypass node access' are eligible for the wild world of node access module control..

• If a user's role has permission to create or edit a content type, or to edit their own posts in that content type, that ability will always be allowed regardless of your node access module's configuration. Delete access is included in the 'edit' permission. If you want to control creating, editing, or deleting of your nodes with a node access module, be sure to not give your users these permissions in the permissions table.

• If your content type comes from an additional module (forum, event, etc.) other than cck/fields, it may have its own permissions to set. Giving a role these permissions will also supersede the use of any node access module.

• Node access modules always GRANT access and never restrict it (it is a whitelisting rather than a blacklisting system). Combining multiple node access modules may produce undesirable results (e.g. if one module grants access and another doesn't, access IS granted). If you need the combined power of several node access modules in such a way that access is only granted if all controlling access modules provide a grant, take a look at the generic and powerful Access Control Bridge. Other possibilities are the Deny access module, as well as the old Module Grants.

• The four types of possible grants on a node are: view, update, create, and delete. You can use Devel module's devel_node_access to analyze a node's node access grants.

• The node access table in the database can become confused if you have, for example, toyed with multiple node access modules or come into contact with a deranged one. If you have been involved with risky node access behaviors you should rebuild your permissions. You can find this option in Drupal 6 at admin/content/node-settings which is the 'Post Settings' configuration screen, and in Drupal 7 at admin/reports/status report/rebuild permissions. It is rarely necessary.

To find a suitable module, you may want to search for projects tagged "content access", or browse the capsule reviews below.

General purpose modules for Drupal 7

Tables key

• ?

• Unsure, and unclear from the project page. You should check and, please, correct this piece of information.

Abbreviations used in the “D6”, “D7” and “D8” columns

• D6

• Drupal 6

• D7

• Drupal 7

• D8

• Drupal 8

• 0

• none: no release available.

• a

• alpha: 1^st stage of complete project, buggy (usually very buggy).

• ß

• beta: complete project to be tested, still buggy.

• dev

• development: module not complete yet, probably extremely buggy.

• rc

• release candidate: complete project to be tested, possibly stable.

• st

• stable: tested complete project, suitable for production website (though a few secondary bugs might remain).

Although all modules are supposed to reach the stable stage, quite many are abandoned before that.

Abbreviations used in the “permission” column:

• a

• all permissions together, i.e. the module itself doesn't manage the permissions one by one.

• c

• create new content.

• d

• delete.

• r

• read, view.

• w

• write, edit.

The “permission” column lists the permissions managed by the said module. Note that, in this column, the abbreviated permissions are not separated by commas. For instance, “rw” means “read and write”.

This table is sorted by popularity - the number of sites reporting using the D7 version of the module. Current order based on stats from drupal.org for week of 21 February 2015.

Specialised modules for Drupal 7

Old modules with no to little hope to reach a Drupal 7 production release

Access modules

Security Modules lists some access modules and http://drupal.org/taxonomy/term/69 lists every module with the security tag.

Generic modules

Nodeaccess

Users with the 'grant node permissions' permission will have a grant tab on node pages which allows them to grant access to that node by user or role. Administrators can set default access controls per content type, and also define which roles are available to grant permissions to on the node grants tab.

Access control list modules

The ACL module, short for Access Control List, is an API for other modules to create lists of users and give them access to nodes. It has no UI of its own and will not do anything by itself; install this module only if some other module tells you to.

Content access

This module allows you to manage permissions for content types by role and author. It allows you to specify custom view, edit and delete permissions for each content type. Optionally you can enable per content access settings, so you can customize the access for each content node.

Flexi access

This module provides a simple and flexible interface to the ACL (Access Control List) module. It will let you set up and manage ACLs naming individual users that are allowed access to a particular node. The grants managed by the module are: View (read), update (edit), delete.

Forum access

This module changes your forum administration page to allow you to set forums private. You can control what user roles can view, edit, delete, and post to each forum. You can also give each forum a list of users who have administrative access on that forum (AKA moderators).

Image gallery access

This module changes your image gallery administration page to allow you to set image galleries private. You can control what user roles can view, edit, delete and post to each gallery. You can also give each gallery a list of users who have administrative access on that gallery (AKA moderators).

CCK field based modules

Nodeaccess userreference

Allows you to configure a CCK user reference field so that the user whom is referenced in a node is granted access to view the node. There are also options to give the user access to edit or delete the node.

Nodeaccess Nodereference

Gives access to users if they have access to a referenced node. Checks view, update, and delete grants.

Node access auto reference

Gives automatic access to users if they are referenced somehow to this node.
It's scanning automatically for references with unlimited deep path, so you don't need to worry anymore how to configure your permissions correct, because it's checking for references automatically.

Taxonomy based

Use these modules to control access based on those tags, vocabularies, and terms you already use, if you use them. Classification, taxonomy and tagging modules lists modules to help you classify and tag content.

Taxonomy Access Control

Access control for user roles based on taxonomy categories (vocabulary, terms).

Connect roles to terms. Useful if everyone has the right role. A good way to control a lot of people when they slot easily into a few roles.

Taxonomy Access Control Lite

This module restricts access so that some users may view content that is hidden from others. A simple scheme based on taxonomy, roles and users controls which content is hidden.

Take the Taxonomy Access Control role based access and add user based controls. Lets you assign users to roles and give the roles access to nodes by term but then lets you give special access to those annoying management types who refuse to wait while you create a new role. Also gives you a quick way to let contractors and temps grab quick access to resources. You know the situation. Hey it is seven minutes before your contract runs out. Rearrange the CRM system to include images the same as Facebook. I will give you access to the 398 nodes you have to change. Fix all the spelling mistakes while you are at it.

Taxonomy access user

Taxonomy access with inheritance.

Modules that contain node access modules

Workflow

The workflow module allows the creation and assignment of arbitrary workflows to Drupal node types. Workflows are made up of workflow states. For example, a workflow with the states Draft, Review, and Published could be assigned to the Story node type.

Organic Groups

Enable users to create and manage their own 'groups'. Each group can have subscribers, and maintains a group home page where subscribers communicate amongst themselves.

Domain

The Domain Access project is a suite of modules that provide tools for running a group of affiliated sites from one Drupal installation and a single shared database. The module allows you to share users, content, and configurations across a group of sites such as:

Modules for use by other modules

Node Access Relation

Node Access Relation allows content access permissions to be set for users referenced via relations created by the Relation module.

Relativity access

This module enables access control based on (and so requires) the Node Relativity module. It propagates the grants from a node to its descendants. You should use another module like nodeaccess to provide the grant to the ancestors.

Ubercart node access

UC Node Access lets you attach Node access features to products in your Ubercart store. These features allow customers who purchase the product to receive view access to nodes on your site either indefinitely or for a limited time based on the feature's settings. UC Node Access does not handle access grants itself but rather depends on other modules to define handlers that integrate UC Node Access with the various node access modules developed for Drupal.

User points node access

The Drupal userpoints nodeaccess module enables you to sell access to a single node for a specific category and amount of userpoints.

Ecommerce Node Access Product

Provides 'Node Access' settings for product nodes, whereby users who purchase the product are granted view access to content, which can be predefined either by category, by node, or by view.

Modules that alter the menu to allow access to give edit access

These modules bypass the node access system and instead alter access of node/%/view, node/%/edit and node/%/delete, so may have issues scaling.

Node access

Menu node edit

Allows node editing access based on menu relationships.