Last updated August 2, 2016. Created on June 12, 2008.
Edited by smk-ka, dman, mr.ashishjain, JoshuaMaddux. Log in to edit this page.

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: 1st 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.

Module name D6 D7 D8 smallest content unit smallest user unit permissions characteristics
module name D6 D7 D8 smallest content unit smallest user unit permissions characteristics
ACL st st a node list of users rwd Helper module. Provides API for other modules. Only install if required by other modules.
Nodeaccess st st 0 node user rwd Adds "Grant" tab where you assign read/edit/delete permissions to individual nodes by role and/or user.
Workbench access 0 st a node editorial section wc Allows node editing access based on "Taxonomy" or "Menu" modules.
Node access user reference st st 0 content with field provided by module "Entity reference" user a? Needs 3 other modules to work.
Node view permissions 0 st st content type role r Of very simple use: adds options "View own content" and "View any content" for each content type on permissions page.
Taxonomy access control lite st st st content with taxonomy term user a? Taxonomy-based. Designed to be simpler than "Taxonomy access control" module.
Node access node reference st st 0 content with field provided by module "Entity reference" user rwd Gives content access permissions to users if they have access to content that is referenced with entity reference. Needs 3 other modules to work.
Workbench OG 0 ß 0 node group? organic group wcd, publish Organic group roles can be defined to be responsible to perform different transitions that will move content from the different stages.
Taxonomy tools 0 st 0 taxonomy term, node with taxonomy term role a? Control access to taxonomy terms and nodes associated with taxonomy terms.
Flexi access 0 st 0 node list of users rwd Interface to ACL module
Restrict node page view 0 st 0 node type role r Only controls direct access by URL.
Hidden nodes st st 0 content type role r Withdraw read, edit and delete permissions together.
Access Control Bridge 0 st, but unsupported 0 node user rwcd Creates a working interplay between all enabled access control modules by requiring each access module controlling the node to grant access.
Node access password st st 0 node node password bearers r Each node generates only one password, allowing to see it.
Access by term 0 st 0 node with taxonomy term user with taxonomy term rwd Grants are based on the relationship between the user->term<-node.
Deny access 0 st 0 content type role rwcd Overrides access granted by other node access modules and/or core.
Groups, Communities and Co (GCC) 0 st ? ? group wcd, publish Manage groups or users.
Access By Reference 0 st 0 node user w Extends edit privileges to referenced users, to editors of referenced nodes, and/or to users with shared value in their user profile.
Workflow Content Permissions st st 0 workflow node field role? rw Manage permissions to edit or view fields of a node that participates in a Workflow for each state.
Node access keys 0 st 0 content type role r Helps to grant users temporary view permission.
Access User Lists(AUL) 0 st 0 node user rwd Extends node access system per user. Has graphic interface in 2.x. version.
Node access relation 0 dev 0 relation type user rwd Based on the "Relation" module.
Privacy per user st dev 0 page element user r Enables privacy settings per user, similar to the privacy settings on a site like Facebook.
Directory based access control (ACL) 0 st 0 directory role rw, add file, move file etc. Directory based access control

Specialised modules for Drupal 7

Key: see “General purpose modules for Drupal 7” above.
module name D6 D7 smallest content unit smallest user unit permissions characteristics
module name D6 D7 smallest content unit smallest user unit permissions characteristics
Commerce file 0 st file user r Submodule of the "Commerce" module, designed to sell file access.
Private files download permission 0 st file user r Designed to restrict file download access.
Forum access st st forum role rwd, post For private forums
OG Forum D7 0 st forum user group rw, post?
User field privacy 0 st profile field the one group of all people except the user himself (and the site administrator) r Allows private fields in the user profile.
Profile2 privacy 0 st profile field role r Manage access to user profile fields.
Node menu permissions 0 st menu link role w Provides permissions to edit the menu link, while not having permissions to administer whole menus.
Term per role 0 st taxonomy term page role r Allows you to restrict access to term page based on user roles.
Node access book 0 st book role, or users defined by another content access module r Gives content access permissions on a book child page if users have access to the root of the book, typically provided by another node access module.
Book access rc st book user rwd, add book/child pages Allows for per-book permissions.

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

Key: see “General purpose modules for Drupal 7” above.
module name D6 D7 smallest content unit smallest user unit characteristics
module name D6 D7 smallest content unit smallest user unit characteristics
Content access st ß node user list (with ACL)
Node access auto reference st 0 content with field provided by module "Entity reference" user Needs 3 other modules to work.
Taxonomy access control st st content with taxonomy term role Taxonomy-based.
Taxonomy access user st 0 content with taxonomy term user Taxonomy-based. Access follows taxonomy inheritance.
Node relativity access control st 0 node ? Based on the "Node relativity" module and grants automatically the permissions to the node's offspring.
Node access st 0 node ? Bypass the node access system.
Menu node edit st 0 node with menu item ? Bypass the node access system. Allows node editing access based on menu relationships.

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.

Looking for support? Visit the Drupal.org forums, or join #drupal-support in IRC.

Comments

coreyp_1’s picture

Virtual Roles

Virtual Roles is an API that allows Roles to be assigned to users on a per-page basis depending on conditions at that time. For example, A role called "VR: Editor" could be created, and VR could then assign it to a user who is looking at a node and has a relationship to the node's author. If the user is viewing a different node, however, the relationship would not exist for that node's author, and therefore would not receive the "VR: Editor" role.

With this system, different tests/contexts can be written so that roles may be applied in any custom way needed.

texas-bronius’s picture

I am not a rabble rouser, but once I got over the mantra "don't hack core," I found following node.module patch described here quite useful:
http://www.johnandcailin.com/blog/cailin/implementing-hookaccess-cck-con...
within, it points to a D6 patch to node.module to provide hook_nodeapi $op='access':
http://drupal.org/files/issues/nodeapi_access_2.patch

--
http://drupaltees.com
80s themed Drupal T-Shirts

dotist’s picture

Hi,

Thanks for the overview. I've been trying to develop a site with complicated access controls and am running into big problems with multiple access modules canceling out each other's grants.

So what is the recommended approach if the level of access sophistication exceeds the scope of any one module? I suppose writing one's own custom module? Or perhaps implementing hook_access as mentioned in the previous comment? I'm trying to set something up that, if it would work, would combine Node Access User Reference, Node Access Node Reference, Taxonomy Access Control, and a blacklisting functionality that I haven't found a solution to yet.

Any tips would be much appreciated!

dianacastillo’s picture

This article barely mentions the "Simple Access " module, which is the best one and easiest to use.

Diana Castillo

nithinkolekar’s picture

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

With compare to "view published content" permission, where it will disallow node view with "Access Denied" but allow to generate menu links which is quite nice for user to navigate to content. It at least shows user what is available on site.

But when "Content Access settings" is applied , then it will restrict access content as well doesn't generate menu links also :(.

Is there any module which provide option to set restriction just for content but allow menu generation.

goedsole’s picture

Just for completeness sake it would be nice to see "0" listed in Abbreviations used in the “D6” and “D7” columns. I assume this means "not available in this release".

pkiff’s picture

Done.

nsputnik’s picture

The state of access control modules is a mess. Someone should round up the most popular modules and modules known to conflict and make a single module with multiple sub modules with the expectations form an admin's perspective that everything should work together. Perhaps for D8?

manarak’s picture

yep... when I saw the list I thought "you have to be kidding".

Permissions based on user, role and usergroup should be a Drupal core feature.
It was so easy and powerful in Postnuke.
For usergroups, Drupal should have them in core, as well as for permissions where it has reinvented the wheel... a huge, heavy, square wheel.