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 you find that there is a company that repeatedly spams your forums with advertisements and marketing information? Or, what happens if you want only people from a certain company to access your site?

Problems of this nature can really be a thorn in your 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 tab on the access control page under the administer main menu item. 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. 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[email protected] will have a deny rule created after Add rule has been clicked.

Go ahead and create a rule like this one, and once you are done you will see 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. Let's say that you wanted to ban someone who runs a small spamming business. Simply blocking their current email address is not really sufficient, because they can simply create another address and use that one to register with Drupal. If you know that the addresses come from one location, such as:

<some characters>@irritating_spammer.com

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 in @hotmail.com and then attempt to register an account on the site. You should find that Drupal presents you with 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 a Hotmail address. In this case, you need to set an Allow rule as well. If it so happens that the email address of the person is [email protected], then you could set the allow rule by selecting the appropriate options to cater for this on the add rule page.

Your rules would then look something like this:

What this does is ban all Hotmail addresses on 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 some time, you might find that the set of rules that are in place can become slightly confusing, or alternatively, 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. Remember to check that all the rules you add have the desired affect 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 you find that is particularly suited to your needs.

Of special interest are the node privacy byrole and Path Access modules, which provide an alternative method of controlling access to content. Having seen how the Taxonomy Access module worked, you should feel confident enough to work with any of these contributions assuming you are not able to achieve precisely what you want already.