Exploring Node Access in Drupal

Node access is not an uncommon topic in the Drupal community so why bother writing about it? Well, if you are new to Drupal or if you have been around it for awhile, unless you have had a need to manage content access, you probably haven't spent a lot of time thinking about your options. In this short article I am going to explore the idea of node access in Drupal and different ways to view it.
<!--break-->
What is meant by node access? If you search for node access on the Drupal site, you will encounter multiple module projects addressing the management of who can view, edit, and/or delete a node. In other words, permissions. This makes sense but there is one other perspective to consider as well; the link to the node. You know, the menu item or list where the title is a link to the full node. The link is what your visitors use to "access" the full node.
Permission Perspective
Let's start with the permissions perspective. There are three aspect I want to bring to your attention.

  • Open: Open refers to all content on the site being available without restriction, without login. This is the simplest setting and by default, Drupal does a bang up job at this.
  • Partially Open: This state means that the visitor to your site can see some portion of your node, typically the title and teaser.
  • Closed: This state is like the off switch. Without permission you don't get to see any part of the node let alone edit or delete it.

Partially Open
Partially open is a "feature" supported by Drupal's core permission. This is not obvious until you create a View of your nodes. What happens is Drupal's core node access process does not pay attention to pages or blocks created by the View module. So if you set your permissions such that a particular role (such as anonymous) can't view any content nodes, nodes showing in a View will be visible. Drupal will deny access to

  • the nodes published to the front page
  • any node linked from the menu system
  • taxonomy term teaser pages
  • search results.

Some see the partially open feature more as a problem. Others find it an advantage.
Sample Scenario 1
Assume you have a blog style site where you share important tips from experts in your field. You want others in your field to come see the tips but you want them to log in to view the full tip (or node). You might do the following.

  • Go to User Management > Permissions and uncheck the box that allows anonymous to view any content.
  • Create a teaser View of your posts.
  • Make the teaser View your homepage via the site information settings.
  • Go to Site Configuration > Error Reporting and enter a path in the 403/access denied field that takes your visit to a sign up page or contact form.

This is a quick and easy approach to providing a peek at your nodes but not full access.
Sample Scenario 2
Assume the above scenario but this time you use the contributed module called Premium.
This is useful on a news or membership site where teasers are available to the general public but the full body is only available to privileged users. Premium nodes appear in listings with full title and teaser available to anyone. If a user does not have adequate privileges, the body is replaced with an administrator-defined message (for example, an invitation to join the site).
I am not going into how to use this module but I think you get the point.
Closed
Most of the contributed modules are all about getting rid of partial node access. If you are used to using Views and relying on partial openness, you will be surprised when you install a module like Content Access and find that the content in your View blocks and pages disappear. For most, this is a good thing but if you are shopping for that partial open feature, it is not apparent what you will get when reading the module description. The Premium module makes the partial access feature very clear.
Sample Scenario
Assume you have a site with content open to the public and content that is not. With some planning you created a content type for content that is for public consumption and a content type for content that requires the visitor to log in to view the restricted content nodes. Planning ahead allowed you to use the Content Access module (which controls access at the content type and node levels). One way to give your visitor access to your restricted nodes is to create a menu with links directly to restricted nodes. Another approach would be to provide links to taxonomy terms. With the appropriate permissions, your visitors will see a teaser page of restricted nodes. Of course, if your visitor doesn't have the right permissions when they click on your menu links, they will get an access denied message. Remember to go to Site Configuration > Error Reporting and enter a path in the 403/access denied path that takes your visit to a sign up page or contact form.
Links Perspective
While planning access to your nodes, you need to consider how your visitors will find your content or at least know what there is to be found. You probably know most of these options:

  • menus
  • View lists
  • Drupal default homepage list
  • search results
  • "read more"
  • manually created blocks/pages with embedded links
  • taxonomy term links

These are the most common methods for giving your visitors "access" to your nodes. However, when you start restricting access via some type of permission controls, you need to think about what your anonymous visitor will experience and how to make that possible. How will you get your visitor interested enough in your site content so that they want to log in?
As you saw from the examples above, depending on what you want to allow and your method for controlling permission-based access, you need to consider the links perspective during this process.
Sample Scenario 1
In scenario 1 above, you decided that anonymous can't view any content. If you use this method, you create a situation where you won't be able to have the common public pages such as About on your site. They will be blocked.
Sample Scenario 2
When your visitors see a teaser list of nodes, one way they know that there is more content to be seen is by the "read more" link. The "read more" promotes access to your nodes. In scenario 1 above, however, if you rely on a View teaser, you won't have the "read more" link that you see on the front page teaser list and the taxonomy term teaser list. You can get around this issue by theming the "read more" link into the View display. So, by considering the method by which your visitor will access your nodes, along with whether you want them to access your nodes, is important to the planning process.
Summary
There are numerous scenarios to consider when trying to come up with the node access scenario that is right for you and your site. I hope that some of the observations noted above help give you something to think about as you plan ahead for how you are going to manage node access on your site.