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 implementing an access control policy will ensure you don't end up with any nasty surprises down the line.
Specifically, this article will look at Planning an access policy, Roles, Users, and Access rules.
Before we continue, it is worth pointing out that at the moment of adding the basic functionality 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 the major changes to the site are completed, 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.
Planning an Access Policy
When you think about how your site should work, focus in on what will be required of yourself, other community members, or even anonymous users. For instance:
* 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 the site should grow organically with the community, and so you want to be extremely flexible in your approach. However, you can take it as given that Drupal's access policies are already flexible, given how easy it is to reconfigure, so it is good practice to start out with a sensible set of access rules, even if they are going to change over time. If you need to make modifications later, so be it, but at least there will be a coherent set of rules from the start.
The first and foremost rule of security that can be applied directly to our situation is
Grant a user permissions sufficient for completing the intended task, and no more!
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. 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 remit.
One upshot of this is that it is 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.
A role constitutes a number of permissions that define what actions any members of that role can and can't perform.
We will explore roles in detail in the next section!
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.
From the previous diagram you can see that the Anonymous users role has 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.
Remember, it is not compulsory that forum moderators encapsulate all the permissions of the anonymous users. You can assign any permissions to any role—it's just that in this context it makes sense that a forum moderator should be able to do everything an anonymous user can and more.
Of course, the blog writers have a slightly different remit. While they share some privileges in common 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 which roles are best for the site, but before attempting this it is important to ask: What are roles and how are they used in the first place? To answer this question, let's take a look at the practical side of things in more detail.
Roles
It may seem a bit odd that we are not beginning a practical look at access control with a discussion on users. After all, it is all about what users can and cannot do! The problem with immediately talking about users is that the focus of a single user is too narrow, and we can learn far more about controlling access by taking a more broad view using roles. Once we have learned everything there is to know about roles, actually working with users becomes a trivial matter.
As mentioned, a user role in Drupal defines a set of rules that must be obeyed by all the users in that role. It may be helpful to think of a role as a character in a play. In a play, an actor must always be true to their character (in the same way a user must be faithful to their role in Drupal)—in other words, there is a defined way to behave and the character never deviates (no matter which actor portrays the character).
Creating a role in Drupal is very easy. Click the User management link under Administer and select the Roles tab to bring up the following:
As you can see, we have two roles already defined by default—the anonymous user and the authenticated user. It is not possible to change these, and so the Operations column is permanently set to locked. To begin with, the anonymous user (this is any user who is browsing the site without logging in) has very few permissions set, and you would more than likely want to keep it this way, despite the fact it is possible to give them any and all permissions.
Similarly, the authenticated user, by default, has only a few more permissions than the anonymous user, and it is also sensible to keep these to a minimum. We will see in a little while how to go about deciding who should have which permissions.
In order to add a new role, type in a name for the role and click Add role, and you're done. But what name do you want to add? That's the key question! If you are unsure about what name to use, then it is most likely you haven't defined the purpose of the role properly. To see how this is done, let's assume we require a forum moderator who will be a normal user in every way, except for the ability to work directly on the forums (to take some of the burden of responsibility off the administrator's hands) to create new topics, and to edit the content if necessary.
To get the ball rolling, type in forum moderator and click Add role—actually, you might even want to be more specific and use something like conservation forum moderator if there will be teams of forum moderators—you get the general idea.
Now the roles page should display the new role with the option to edit it, shown in the Operations column. Click edit role in order to change the name of the role or delete it completely. Alternatively, click edit permissions to deal with the permissions for this specific role (we discuss permissions in a moment so let's leave this for now).
Our work is just beginning, because now we need to grant or deny the various permissions that the forum moderator role will need in order to successfully fulfill its purpose. New roles are not given any permission at all to begin with—this makes sense, because the last thing we want is to create a role only to find that it has the same permissions as the administrative user.
Chances are you will need to add several roles depending on the needs of the site, so add at least a blogger user that can edit their own blog—we will need a few different types to play with later on.
Let's move on and take a look at how to flesh out this new role by setting permissions.
This article has been extracted from: Building Powerful and Robust Websites with Drupal 6
Building Powerful and Robust Websites with Drupal 6 Build your own professional blog, forum, portal or community website with Drupal 6
* Set up, configure, and deploy Drupal 6
* Design and implement your website's look and feel
* Easily add exciting and powerful features
* Promote, manage, and maintain your live website
For more information, please visit:
www.PacktPub.com/drupal-6-create-powerful-websites/book
Permissions
In order to work with permissions, click the Permissions link under User management and you should be presented with a screen much like the following (notice the new forum moderator role on the right-hand side of the page):
As you can see, this page lists all of the available permissions down the left-hand column and allows you to enable or disable that permission by checking or un-checking boxes in the relevant column. It is easy enough to see that one traverses the list, selecting those permissions required for each role. What is not so easy is actually determining what should and shouldn't be enabled in the first place.
Notice too that the permissions given in the list on the left-hand side pertain to specific modules. This means that if we change the site's setup by adding or removing modules, then we will also have to change the permissions on this page.
Most times a module is added, you will need to ensure that the permissions are set as required for that module, because by default no permissions are granted.
What else can we learn from the permissions page shown in the previous screenshot? Well, what does each permission precisely mean? There are quite a few verbs that allow for completely different actions. The following lists the more common, generic ones, although you might find one or two others crop up every now and then to cater for a specific module:
* administer: gives the user the ability to affect the function of a module. For example, granting administer rights to the locale module means that the user can add or remove languages, manage strings, and even export .po files. This permission should only ever be given to trusted users, and never to anonymous users.
* access: gives the user the ability to make use of a module without being able to affect it in any way. For example, granting access rights to the comment module allows a user to view comments without being able to delete, edit, or reply to them.
* create: gives the user the ability to create content of some sort. For example, granting rights to create stories allows users to do so, but does not also give them the ability to edit those stories.
* edit any/own: gives the user the ability to work with either anyone's content or specifically the content they have created—depending on whether edit any or edit own is selected. For example, granting edit own rights to the blog module means that the user can modify their own blogs at will.
* delete any/own: applies to content related modules such as Node and empowers users to remove either anyone's content or confine them to removing only content posted by themselves. For example, setting delete own blog entry allows users to take back any blog postings they may regret having published.
There are also other module-specific permissions available, and it is recommended that you play around and understand any new permission(s) you set.
Previously, assigning the edit own permission automatically provided the delete own permission. For added security, delete own permissions for individual core content types have been removed from all roles and should be assigned separately.
How do we go about setting up the required permissions for the forum moderator user? If we look down the list of permissions shown on the Permission page, we see the following forum-related options (at the moment, the forum moderator permissions are those in the outermost column):
Enabling these three options, and then testing out what new powers are made available, should quickly demonstrate that this is not quite what we want.
If you are wondering how to actually test this out, you need to create a new user and then assign them to the forum moderator role. The following section on Users explains how to create new users and administer them properly. Jump ahead quickly and check that out so that you have a new user to work with if you are unsure how it is done.
The following point might make your life a bit easier:
Use two browsers to test out your site. The demo site's development machine has IE and Firefox. Keep one browser for the administrator and the other for anonymous or other users in order to test out changes. This will save you from having to log in and log out whenever testing new permissions.
When testing out the new permissions one way or another, you will find that the forum moderator can access and work with all of the forums—assuming you have created any.
However, notice that there are node module permissions available, which is quite interesting because most content in Drupal is actually a node. How will this affect the forum moderator? Disable the forum module permissions for the forum moderator user and then enable all the node options for the authenticated user before saving and logging out.
Log back in as the forum administrator and it will be clear that despite having revoked the forum based options for this user, it is possible to post to or edit anything in the forum quite easily by selecting the Create content link in the main menu. Is this what you expected?
It should be precisely what you expect because the forum moderator is an authenticated user, so they have acquired the permissions that came from the authenticated user. In addition, the forum posts are all nodes, and any authenticated user can add and edit nodes, so even though the forum moderator is not explicitly allowed to work with forums, through generic node permissions we get the same result:
Defined roles are given the authenticated user permissions.
Actually, the result is not entirely the same because the forum moderator can now also configure all the different types of content on the site, as well as edit any type of content including other people's blogs. This is most certainly undesirable, so log back in as the primary user and remove the node permissions (except the first one) from the authenticated user role. With that done, you can now spend some time building a fairly powerful and comprehensive role-based access control plan.
As an addendum, you might find that despite having a goodly amount of control over who does what, there are some things that are not easily done without help from elsewhere.
Users
A single user account can be given as many or as few permissions as you like via the use of roles. Drupal users are not really anything unless they already have a role that defines the manner in which they can operate within the Drupal framework. Hence, we discussed roles first.
Users can be created in two ways. The most common way is by registering on the site—if you haven't already, go ahead and register a new user on your site by clicking the Create new account link on the homepage just to test things out. Remember to supply a valid email address otherwise you won't be able to sign in properly. This will create an authenticated user, with any and all permissions that have been assigned to the authenticated user role.
The second way is to use the administrative user to create a new user. In order to do so, log on as the administrative user and click on Users in User management under Administer. Select the Add user tab and follow the instructions on that page. For example, I created a new forum moderator user by ensuring that the relevant role was checked:
You will need to supply Drupal with usernames, email addresses, and passwords. Once there are a couple of users to play around with, it's time to begin working with them.
Administering Users
The site's administrator is given complete access to the other users' account information. By clicking on the edit link shown to the right of each user account (under the Operations column heading) in the Users page under User management, it is possible to make any changes you require to a given user.
Before we do though, it's worth noting that the administration page itself is fairly powerful in terms of being able to administer individual users or groups of users with relative ease:
The upper box, Show only users where, allows you to specify several filter conditions to cut down the result set and make it more manageable. This will become more and more important as the site accumulates more and more users. Once the various filter options have been implemented, the Update options allow you to apply whatever changes are needed to the list of users selected (by checking the relevant checkbox next to their name).
Having both broad, sweeping powers as well as fine-grained control over users is one of the most valuable facilities provided by Drupal, and you will no doubt become very familiar with this page in due course.
Click on the edit link next to the forum moderator user and take a look at the Roles section. Notice that it is now possible to stipulate which roles this user belongs to. At present there are only two new roles to be assigned (yours might vary depending on which roles have been created on your setup):
Whenever a user is added to another role, they obtain the combined permissions of these roles. With this in mind, you should go about delegating roles in the following fashion:
1. Define the most basic user of the site by setting the anonymous user permissions.
2. Set permissions for a basic authenticated user (i.e. any Tom, Dick or Harry that registers on your site).
3. Create special roles by only adding the specific additional permissions that are required by that role, and no more. Don't re-assign permissions that the authenticated user already has.
4. Create new users by combining whatever roles are required for their duties or needs.
If you follow the steps above, you will be sure to always give the correct permissions to each role by avoiding redundancy and only applying permissions incrementally by role. Basically, you are building up a user's permissions from the most basic to the most complex without having to assign every single permission each time. It should be commonsense (although not a technical obligation) that a forum moderator would have all the permissions of an anonymous and authenticated user, plus a few more. Looking back to the first diagram in the section Planning an Access Policy you can see that, in this case, we would:
1. Define the anonymous user and authenticated user role permissions—an authenticated user should have all the permissions of an anonymous user, plus whatever else is needed by a basic site user.
2. Create new roles with only the additional permissions needed for both the forum moderator and blog user respectively—other than those given to the authenticated user.
3. Assign blog writers to the blog user role (they are automatically given the permissions granted to an authenticated user), and do the same for forum moderators and their role.
Other than using that strategy for assigning roles to users, the rest, as they say, is history. Play around with any new roles you create to ensure they behave as you expect and then move on.
User Settings
This section looks at how the site treats users, rather than discussing what users can and cannot do. However, you will find that some of the information in this section is important for the look and feel of the site.
Click on User settings under the User management. The following set of options is provided, beginning with user registration settings, as follows:
User Access Control in Drupal 6
In this article by David Mercer, we will look at an entirely different aspect of running a Drupal website. Once we have added the functionality to the site, we now have to give some thoughts about 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 is required, at some stage you will have to make decisions about who can do what, and Drupal makes sure that it is possible to do precisely this.
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 implementing an access control policy will ensure you don't end up with any nasty surprises down the line.
Specifically, this article will look at Planning an access policy, Roles, Users, and Access rules.
Before we continue, it is worth pointing out that at the moment of adding the basic functionality 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 the major changes to the site are completed, 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.
Planning an Access Policy
When you think about how your site should work, focus in on what will be required of yourself, other community members, or even anonymous users. For instance:
* 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 the site should grow organically with the community, and so you want to be extremely flexible in your approach. However, you can take it as given that Drupal's access policies are already flexible, given how easy it is to reconfigure, so it is good practice to start out with a sensible set of access rules, even if they are going to change over time. If you need to make modifications later, so be it, but at least there will be a coherent set of rules from the start.
The first and foremost rule of security that can be applied directly to our situation is
Grant a user permissions sufficient for completing the intended task, and no more!
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. 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 remit.
One upshot of this is that it is 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.
A role constitutes a number of permissions that define what actions any members of that role can and can't perform.
We will explore roles in detail in the next section!
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.
From the previous diagram you can see that the Anonymous users role has 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.
Remember, it is not compulsory that forum moderators encapsulate all the permissions of the anonymous users. You can assign any permissions to any role—it's just that in this context it makes sense that a forum moderator should be able to do everything an anonymous user can and more.
Of course, the blog writers have a slightly different remit. While they share some privileges in common 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 which roles are best for the site, but before attempting this it is important to ask: What are roles and how are they used in the first place? To answer this question, let's take a look at the practical side of things in more detail.
Roles
It may seem a bit odd that we are not beginning a practical look at access control with a discussion on users. After all, it is all about what users can and cannot do! The problem with immediately talking about users is that the focus of a single user is too narrow, and we can learn far more about controlling access by taking a more broad view using roles. Once we have learned everything there is to know about roles, actually working with users becomes a trivial matter.
As mentioned, a user role in Drupal defines a set of rules that must be obeyed by all the users in that role. It may be helpful to think of a role as a character in a play. In a play, an actor must always be true to their character (in the same way a user must be faithful to their role in Drupal)—in other words, there is a defined way to behave and the character never deviates (no matter which actor portrays the character).
Creating a role in Drupal is very easy. Click the User management link under Administer and select the Roles tab to bring up the following:
As you can see, we have two roles already defined by default—the anonymous user and the authenticated user. It is not possible to change these, and so the Operations column is permanently set to locked. To begin with, the anonymous user (this is any user who is browsing the site without logging in) has very few permissions set, and you would more than likely want to keep it this way, despite the fact it is possible to give them any and all permissions.
Similarly, the authenticated user, by default, has only a few more permissions than the anonymous user, and it is also sensible to keep these to a minimum. We will see in a little while how to go about deciding who should have which permissions.
In order to add a new role, type in a name for the role and click Add role, and you're done. But what name do you want to add? That's the key question! If you are unsure about what name to use, then it is most likely you haven't defined the purpose of the role properly. To see how this is done, let's assume we require a forum moderator who will be a normal user in every way, except for the ability to work directly on the forums (to take some of the burden of responsibility off the administrator's hands) to create new topics, and to edit the content if necessary.
To get the ball rolling, type in forum moderator and click Add role—actually, you might even want to be more specific and use something like conservation forum moderator if there will be teams of forum moderators—you get the general idea.
Now the roles page should display the new role with the option to edit it, shown in the Operations column. Click edit role in order to change the name of the role or delete it completely. Alternatively, click edit permissions to deal with the permissions for this specific role (we discuss permissions in a moment so let's leave this for now).
Our work is just beginning, because now we need to grant or deny the various permissions that the forum moderator role will need in order to successfully fulfill its purpose. New roles are not given any permission at all to begin with—this makes sense, because the last thing we want is to create a role only to find that it has the same permissions as the administrative user.
Chances are you will need to add several roles depending on the needs of the site, so add at least a blogger user that can edit their own blog—we will need a few different types to play with later on.
Let's move on and take a look at how to flesh out this new role by setting permissions.
This article has been extracted from: Building Powerful and Robust Websites with Drupal 6
Building Powerful and Robust Websites with Drupal 6 Build your own professional blog, forum, portal or community website with Drupal 6
* Set up, configure, and deploy Drupal 6
* Design and implement your website's look and feel
* Easily add exciting and powerful features
* Promote, manage, and maintain your live website
For more information, please visit:
www.PacktPub.com/drupal-6-create-powerful-websites/book
Permissions
In order to work with permissions, click the Permissions link under User management and you should be presented with a screen much like the following (notice the new forum moderator role on the right-hand side of the page):
As you can see, this page lists all of the available permissions down the left-hand column and allows you to enable or disable that permission by checking or un-checking boxes in the relevant column. It is easy enough to see that one traverses the list, selecting those permissions required for each role. What is not so easy is actually determining what should and shouldn't be enabled in the first place.
Notice too that the permissions given in the list on the left-hand side pertain to specific modules. This means that if we change the site's setup by adding or removing modules, then we will also have to change the permissions on this page.
Most times a module is added, you will need to ensure that the permissions are set as required for that module, because by default no permissions are granted.
What else can we learn from the permissions page shown in the previous screenshot? Well, what does each permission precisely mean? There are quite a few verbs that allow for completely different actions. The following lists the more common, generic ones, although you might find one or two others crop up every now and then to cater for a specific module:
* administer: gives the user the ability to affect the function of a module. For example, granting administer rights to the locale module means that the user can add or remove languages, manage strings, and even export .po files. This permission should only ever be given to trusted users, and never to anonymous users.
* access: gives the user the ability to make use of a module without being able to affect it in any way. For example, granting access rights to the comment module allows a user to view comments without being able to delete, edit, or reply to them.
* create: gives the user the ability to create content of some sort. For example, granting rights to create stories allows users to do so, but does not also give them the ability to edit those stories.
* edit any/own: gives the user the ability to work with either anyone's content or specifically the content they have created—depending on whether edit any or edit own is selected. For example, granting edit own rights to the blog module means that the user can modify their own blogs at will.
* delete any/own: applies to content related modules such as Node and empowers users to remove either anyone's content or confine them to removing only content posted by themselves. For example, setting delete own blog entry allows users to take back any blog postings they may regret having published.
There are also other module-specific permissions available, and it is recommended that you play around and understand any new permission(s) you set.
Previously, assigning the edit own permission automatically provided the delete own permission. For added security, delete own permissions for individual core content types have been removed from all roles and should be assigned separately.
How do we go about setting up the required permissions for the forum moderator user? If we look down the list of permissions shown on the Permission page, we see the following forum-related options (at the moment, the forum moderator permissions are those in the outermost column):
Enabling these three options, and then testing out what new powers are made available, should quickly demonstrate that this is not quite what we want.
If you are wondering how to actually test this out, you need to create a new user and then assign them to the forum moderator role. The following section on Users explains how to create new users and administer them properly. Jump ahead quickly and check that out so that you have a new user to work with if you are unsure how it is done.
The following point might make your life a bit easier:
Use two browsers to test out your site. The demo site's development machine has IE and Firefox. Keep one browser for the administrator and the other for anonymous or other users in order to test out changes. This will save you from having to log in and log out whenever testing new permissions.
When testing out the new permissions one way or another, you will find that the forum moderator can access and work with all of the forums—assuming you have created any.
However, notice that there are node module permissions available, which is quite interesting because most content in Drupal is actually a node. How will this affect the forum moderator? Disable the forum module permissions for the forum moderator user and then enable all the node options for the authenticated user before saving and logging out.
Log back in as the forum administrator and it will be clear that despite having revoked the forum based options for this user, it is possible to post to or edit anything in the forum quite easily by selecting the Create content link in the main menu. Is this what you expected?
It should be precisely what you expect because the forum moderator is an authenticated user, so they have acquired the permissions that came from the authenticated user. In addition, the forum posts are all nodes, and any authenticated user can add and edit nodes, so even though the forum moderator is not explicitly allowed to work with forums, through generic node permissions we get the same result:
Defined roles are given the authenticated user permissions.
Actually, the result is not entirely the same because the forum moderator can now also configure all the different types of content on the site, as well as edit any type of content including other people's blogs. This is most certainly undesirable, so log back in as the primary user and remove the node permissions (except the first one) from the authenticated user role. With that done, you can now spend some time building a fairly powerful and comprehensive role-based access control plan.
As an addendum, you might find that despite having a goodly amount of control over who does what, there are some things that are not easily done without help from elsewhere.
Users
A single user account can be given as many or as few permissions as you like via the use of roles. Drupal users are not really anything unless they already have a role that defines the manner in which they can operate within the Drupal framework. Hence, we discussed roles first.
Users can be created in two ways. The most common way is by registering on the site—if you haven't already, go ahead and register a new user on your site by clicking the Create new account link on the homepage just to test things out. Remember to supply a valid email address otherwise you won't be able to sign in properly. This will create an authenticated user, with any and all permissions that have been assigned to the authenticated user role.
The second way is to use the administrative user to create a new user. In order to do so, log on as the administrative user and click on Users in User management under Administer. Select the Add user tab and follow the instructions on that page. For example, I created a new forum moderator user by ensuring that the relevant role was checked:
You will need to supply Drupal with usernames, email addresses, and passwords. Once there are a couple of users to play around with, it's time to begin working with them.
This article has been extracted from: Building Powerful and Robust Websites with Drupal 6
Building Powerful and Robust Websites with Drupal 6 Build your own professional blog, forum, portal or community website with Drupal 6
* Set up, configure, and deploy Drupal 6
* Design and implement your website's look and feel
* Easily add exciting and powerful features
* Promote, manage, and maintain your live website
For more information, please visit:
www.PacktPub.com/drupal-6-create-powerful-websites/book
Administering Users
The site's administrator is given complete access to the other users' account information. By clicking on the edit link shown to the right of each user account (under the Operations column heading) in the Users page under User management, it is possible to make any changes you require to a given user.
Before we do though, it's worth noting that the administration page itself is fairly powerful in terms of being able to administer individual users or groups of users with relative ease:
The upper box, Show only users where, allows you to specify several filter conditions to cut down the result set and make it more manageable. This will become more and more important as the site accumulates more and more users. Once the various filter options have been implemented, the Update options allow you to apply whatever changes are needed to the list of users selected (by checking the relevant checkbox next to their name).
Having both broad, sweeping powers as well as fine-grained control over users is one of the most valuable facilities provided by Drupal, and you will no doubt become very familiar with this page in due course.
Click on the edit link next to the forum moderator user and take a look at the Roles section. Notice that it is now possible to stipulate which roles this user belongs to. At present there are only two new roles to be assigned (yours might vary depending on which roles have been created on your setup):
Whenever a user is added to another role, they obtain the combined permissions of these roles. With this in mind, you should go about delegating roles in the following fashion:
1. Define the most basic user of the site by setting the anonymous user permissions.
2. Set permissions for a basic authenticated user (i.e. any Tom, Dick or Harry that registers on your site).
3. Create special roles by only adding the specific additional permissions that are required by that role, and no more. Don't re-assign permissions that the authenticated user already has.
4. Create new users by combining whatever roles are required for their duties or needs.
If you follow the steps above, you will be sure to always give the correct permissions to each role by avoiding redundancy and only applying permissions incrementally by role. Basically, you are building up a user's permissions from the most basic to the most complex without having to assign every single permission each time. It should be commonsense (although not a technical obligation) that a forum moderator would have all the permissions of an anonymous and authenticated user, plus a few more. Looking back to the first diagram in the section Planning an Access Policy you can see that, in this case, we would:
1. Define the anonymous user and authenticated user role permissions—an authenticated user should have all the permissions of an anonymous user, plus whatever else is needed by a basic site user.
2. Create new roles with only the additional permissions needed for both the forum moderator and blog user respectively—other than those given to the authenticated user.
3. Assign blog writers to the blog user role (they are automatically given the permissions granted to an authenticated user), and do the same for forum moderators and their role.
Other than using that strategy for assigning roles to users, the rest, as they say, is history. Play around with any new roles you create to ensure they behave as you expect and then move on.
User Settings
This section looks at how the site treats users, rather than discussing what users can and cannot do. However, you will find that some of the information in this section is important for the look and feel of the site.
Click on User settings under the User management. The following set of options is provided, beginning with user registration settings, as follows:
You might want to consider which of the first three options to select quite carefully, depending on how you envisage the site functioning. For example, allowing everyone to read and post comments to the forums, or do whatever, without needing to register first may be ideal. If this is the case, then it is likely that the only people who would need to register are going to be performing some sort of administrative duties, in which case you would probably want to select the first option, or at least the third option.
If you do go for the third option, then check the user list regularly in order to unblock new users as soon as possible. Note that Drupal can be configured to email the site administrator automatically whenever there is a new user registration application.
Additionally, if you enter a message into the User registration guidelines text area then this will appear during the registration process, as shown in the following screenshot:
I specifically added this note in here because it is fairly well known that new users often log in with the one-time password generated by Drupal, but then fail to add their own password before logging off. When they return, they are then locked out because the one-time password has expired and there is no new one set.
The next section on this page deals with the process of user email customization for the various different type of emails that Drupal sends out. There is an interesting facet to this in that Drupal makes certain variables available for use within the static text that is entered. Let's take a look at how to modify a line or so in order to get the feel for how it works.
By way of example, we will change the Welcome, no approval text from:
Account details for !username at !site
to a slightly sprightlier:
Congratulations !username, you have registered with the !site on !date!
Nothing too complicated here! The keywords preceded by the ! sign are simply placeholders for other values that are inserted into the email, according to how they are set at that particular time. This gives you the ability to personalize correspondence. In this case, the subject of the welcome email for a user registered as David M is now displayed as follows:
The !username, !site, and !date placeholders have been correctly changed to reflect the contents of the variables for that particular setup. There are settings available for several standard emails such as password recovery and welcome (awaiting admin approval). The defaults are fairly sensible and easy to change should you need to. Remember the placeholders that are available for each piece of text are mentioned below the section heading, so play around with them until you are comfortable with their usage:
The final two sections deal with Signatures and Pictures. If you wish to enable Picture support for users, then select Enabled from the list, provide a default picture (if you want one), and click Save configuration (the other settings are fairly self explanatory and sensible, and you can come back at any stage to change them if they are not suitable).
Drupal will set up a pictures folder to hold all of the pictures within the files folder in your Drupal installation. Once everything is done, users will have a new section added to the edit tab of their my account page, like the following figure:
When the picture has been successfully uploaded, it will appear on the my account page, and with the user's blog and forum posts on the site. If the image does not appear and you end up seeing a link, something like the following:
...then you will need to ensure that you set the correct upload module permissions on the Permissions page, as follows:
Remember that since the forum administrator user automatically receives all the permissions of the authenticated user, it is not necessary to enable the view uploaded files permission for the forum administrator as this would be redundant and would make the purpose of your user less clear.
It is possible to control where the user pictures are displayed by selecting the Configure tab of the Themes page under Site building and checking the relevant picture related checkboxes, as shown in the following figure:
Allowing users to incorporate pictures into a site is a good way for people to be able to personalize their contributions, and also gives everyone something visual to associate posts with. This is a great way to foster a community, as it helps give different users an identity of sorts.
Changing the picture is easy! Simply modify it in the Picture section of the user's edit page, as shown in the following screenshot:
That is pretty much the end of the line for configuring users. There are still a few more things we need to discuss with regards to security before we can move on though.
Access Rules
So far it should seem like Drupal has things more or less covered when it comes to ensuring that it is possible to control who does what on the site. This is certainly the case, but there are a few more situations that we have not yet discussed, and may well end up affecting the site at some stage. For example, what happens if there is a company that repeatedly spams your forums with advertisements and marketing information? Or, what happens if only people from a certain company should have access to your site?
Problems of this nature can really be a thorn in the side. Access problems can even end up driving community members away—unless you have the ability to set access rules.
There are some techniques that can be used to set access rules via the Access rules link under User management. To implement any access rules you will need to select the Add rule option, which brings up the following page:
From this you can see that I am in the process of making a rule that denies access based on an email address—more specifically, really@nastyspammer.com. Before we continue on this line, it is important to note that there are both Allow and Deny options available, and these will act based on a supplied Username, E-mail, or Host address given in the Rule type section. The final option, Mask, allows you to specify the actual name of the user or host to which the rule will apply.
In the above case, the email address really@nastyspammer.com will have a deny rule created after Add rule has been clicked.
Go ahead and create a rule like this one, and notice that the rule now appears under the list tab. Now that there is a deny rule in place, how do we go about using it? The answer is that it is already being used. If someone tries to register with the email address supplied in the rule, they will be denied access. As it stands, this is probably not very helpful, because it is unlikely you will know ahead of time what specific email addresses to block.
In order to cater for the times when you aren't entirely sure of the specific address, there are two wildcard characters provided that can serve as generic strings or characters. Imagine you wanted to ban someone who runs a small spamming business. Simply blocking their current email address is not really sufficient, because they can easily create another address and use that one to register. If you know that the addresses come from one location, such as:
...you could use the % character to match whatever characters are present before the @ sign, effectively stopping anyone from that email server from registering, like so:
%@irritating_spammer.com
If you have a Hotmail account, or something similar, try blocking any address that ends with @hotmail.com and then attempt to register an account on the site. Drupal will dutifully display the following message:
A new problem rears its ugly head when it so happens that you don't want to allow Hotmail addresses on the site, with the exception of a close personal friend who is traveling around the world and can only access Hotmail addresses. In this case, you need to set an Allow rule as well. If, for example, the email address of the person is good_friend@hotmail.com, then you could set the Allow rule by selecting the appropriate options to cater for this on the add rule page.
The rules would then look something like the following:
What this does is ban all Hotmail addresses from the site. However, because an allow rule takes precedence over a deny rule, the one and only Hotmail address specified in the single allow rule shown in the screenshot will work fine. Now when your good friend attempts to register, everything will go swimmingly well.
After adding plenty of rules, things can sometimes become slightly confusing and it is simply not feasible to continue attempting to register new names all the time, to ensure that they work according to plan. In this case, use the Check rules tab on the right-hand side of the Access rules page. This allows names of users, email addresses, and hosts to be entered in order to check whether they have access or not. Simply compare these results with your expectations to determine if everything is working as planned.
One final thing to bear in mind is that if you deny access using the host criteria, then this will be enforced throughout the site and not just on the registration pages. For the case of the spammer, you would probably want to deny access to the site in general; so you would select the host option with something like this for the Mask:
%irritating_spammer%
This would then match to any host with irritating_spammer in it. For example:
www.really_irritating_spammer.com
www.mildly_irritating_spammer.com
www.extremelyirritating_spammer.org
www.unbelievably_irritating_spammer.comms.org.co.sz
...and so on.
It is important to realize that this only applies to the host criteria:
If an undesirable user has already registered with an email address that is subsequently blocked, then no action will be taken against them.
Remember to check that all the added rules have the desired effect on the site's access policy. It would be a shame to make a rule that prevented potentially valuable community members from accessing content, causing them to go elsewhere.
I would be remiss if I didn't mention, before finishing off, that there are a number of other user access/authentication-related modules available on the Drupal website. It is probably worthwhile to check these out at http://drupal.org/project/Modules/category/74 in case there is something that is particularly suited to your needs.
Summary
This article provided a good grounding in the basics of controlling access to your site's content. Drupal comes with a large number of facilities and options to ensure proper maintenance of the site by retaining overall control with the administrative user, as well as delegating important jobs to trusted users via the use of roles.
We looked at how to go about planning an access policy. This is not only an important requirement, in terms of making sure the site runs smoothly, but also helps to solidify how the site will eventually work by forcing you to consider many eventualities. A tour of the fundamental aspects of access control in Drupal saw us discussing roles, permissions, and users, and learning how to plan and implement an access policy based on the requirements of the site.
Access rules were then introduced as a further way of controlling who gets into the site, with a discussion on how to use the wildcard characters effectively. Planning, and above all, testing, will help ensure that everything works as intended.
With that, we are done with access control, although you are strongly urged to spend some time playing around with the various options until you are comfortable with being able to make changes and understanding their effects.
About the Author
David Mercer was born in August 1976 in Harare, Zimbabwe. Having always had a strong interest in science, David came into regular contact with computers at university where he graduated cum laude with majors in applied math and math (although he minored in computer science).
As a programmer and professional writer who has been writing both code and books for about nine years, he has worked on a number of well known titles, in various capacities, on a wide variety of topics. His books have sold tens of thousands of copies and have been translated into over 6 different languages to date.
David finds that the challenges arising from the dichotomous relationship between the science (and art) of software programming and the art (and science) of writing is what keeps his interest in producing books piqued. He will no doubt continue to write professionally in the future.
David balances his time between programming, reviewing, writing, and contributing to interesting web-based projects such as RankTracer and LinkDoozer. When he isn't working (which isn't that often) he enjoys playing guitar (generally on stage and unrehearsed) and getting involved in outdoor activities ranging from touch rugby and golf to water skiing and snowboarding. Visit RankTracer or find him on LinkDoozer where he is generally lurking.
