It's time to look at an entirely different aspect of running a Drupal website. Up until now we have focused on adding and organizing the site's basic functionality. We have not yet given any thought to how this functionality is to be accessed, or by whom. As the site grows, you will most likely feel the need to delegate certain responsibilities to various people. Alternatively, you might organize a team of people to work on specific aspects of the site. Whatever your needs, at some stage you will have to make decisions about who can do what, and the good people at Drupal have made sure that it is possible to do precisely this.
In the same vein as the previous chapter, having Drupal simplify the implementation of your access control policies does not mean that the task is a trivial one. There is still much thought that needs to go on behind the scenes in order to create a sophisticated, and above all, effective policy for controlling access to the site. Because of this, we will spend a bit of time exploring the ramifications of the various choices available, instead of simply listing them. Taking a holistic approach to your access control policy will ensure you don't end up with any nasty surprises down the line.
Since we have now been working with Drupal for a little while we will start spreading our wings a bit and use some slightly more advanced methods provided by contributed modules. Specifically, this chapter will look at the following topics:
- Planning an access policy
- Roles
- Permissions—including the use of the Taxonomy Access Control module
- Users
- Access rules
Before we continue, it is worth pointing out that at the moment you are more than likely using the administrative user (user number 1) for all the site's development needs. That is absolutely fine, but once you have finished making any major changes to the site, you should begin using a normal administrative user that has only the permissions required to complete your day-to-day tasks. The next section will highlight the general philosophy behind user access, which should make the reason for this clear.
When you think about how your site should work, you need to focus in on what will be required of yourself, other community members, or even anonymous users. In other words, will there be a team of moderators working to ensure that the content of the site conforms to the dictates of good taste and avoids material that is tantamount to hate speech and so on? Will there be subject experts who are allowed to create and maintain their own content? How much will anonymous visitors be allowed to become involved, or will they be forced to merely window shop without being able to contribute?
Some of you might feel that you want the use of the site to grow organically with the community, and so you want to be extremely flexible in your approach. However, you can take it as given that your site and access policies are already flexible, given how easy it is to make changes in Drupal. This means that no one is exempt from building a proper access control plan to begin with. If you need to change it as time goes by, so be it, but at least there will be a coherent set of roles from the start.
So where do we begin? The first and foremost rule of security that can be applied directly to our situation is to:
Our entire approach is going to be governed by this rule. With a bit of thought you should be able to see why this is so important. Obviously, the last thing anyone wants is for an anonymous user to be able to modify the personal blog of a respected industry expert. This means that each type of user should have carefully controlled permissions that effectively block their ability to act outside the scope of their role.
One upshot of this is that you will find it better to create a larger number of specific roles rather than create a generic role or two, and allow everyone to use those catch-all permissions. Drupal gives us fine-grained control over what users can accomplish, and you should make good use of this facility. It may help to think of your access control using the following figure (this does not necessarily represent the actual roles on your site—it's just an example):
The shaded region represents the total number of permissions available for the site. Contained within this set are the various roles that exist either by default, like the Anonymous users role, or those you create in order to cater for the different types of users the site will require—in this case, the Blog Writer users and Forum Moderator users roles. Each role can then contain any number of users.
From the previous diagram you can see that the Anonymous users have the smallest set of permissions because they have the smallest area of the total diagram. This set of permissions is totally encapsulated by the Forum Moderator users and Blog Writer users—meaning that forum moderators and blog writers can do everything an anonymous user does, and a whole lot more.
Of course, the blog writers have a slightly different remit. While they share some common permissions with the forum administrators, they also have a few of their own. Your permissions as the primary or administrative user encompass the entire set, because there should be nothing that you cannot control.
It is up to you to decide on which roles are best for the site, but before you attempt this it is important to ask: What are roles and how are they used in the first place? To answer this, let's take a look at the practical side of things in more detail.