-->
Previous Table of Contents Next


Advanced Functionality

You may want to exert even more control over your server or customize the operating environment in very specific ways. You can configure the Apache server to support advanced functionality, such as access control and user authentication.

Host-Based Access Control

You can control access to the server, or even a subdirectory of the server, based on the host name, domain, or IP number of the client’s machine. This is done by using the directives allow and deny, which can be used together with order. allow and deny can take multiple hosts:


deny from badguys.com otherbadguys.com

Typically, you want to do one of two things: you want to deny access to your server from everyone but a few other machines, or you want to grant access to everyone except a few hosts. Denying access from all but a few machines is accomplished with these commands:


order deny,allow

allow from mydomain.com

deny from all

This directive means, “Only grant access to hosts in the domain mydomain.com.” This domain could include host1.mydomain.com, ppp.mydomain.com, and the-boss.mydomain.com.

The preceding directive tells the server to evaluate the deny conditions before the allow conditions when determining whether to grant access. Likewise, the “only exclude a couple of sites” case described earlier can be handled by using the following:


order allow,deny

allow from all

deny from badguys.com

order is needed because—again—the server needs to know which rule to apply first. The default for order is deny,allow.

In a third argument to order, called mutual-failure, a condition has to pass the allow and deny rules to succeed. In other words, it has to appear in the allow list, and it must not appear in the deny list, as in the following example:


order mutual-failure

allow from mydomain.com

deny from the-boss.mydomain.com

In this example, the-boss.mydomain.com is prevented from accessing this resource, but every other machine at mydomain.com can access it.


CAUTION:  
Protecting resources by host name is dangerous. It’s relatively easy for a determined person who controls the reverse-DNS mapping for his IP number to spoof any host name he wants. Thus, it’s strongly recommended that you use IP numbers to protect anything sensitive. In the same way, you can simply list the domain name to refer to any machine in that domain. You also can give fragments of IP numbers:

  allow from 204.62.129

This will allow only hosts whose IP numbers match, such as 204.62.129.1 or 204.62.129.130.

Typically, these directives are used within a <Limit> container, and even that within a <Directory> container, usually in an access.conf configuration file. The following example is a good template for most protections; it protects the /www/htdocs/private directory from any host except those in the 204.62.129 IP space:


  <Directory /www/htdocs/private>

  Options Includes

  AllowOverride None

  <Limit GET POST>

  order allow,deny

  deny from all

  allow from 204.62.129

  </Limit>

  </Directory>


User Authentication

When you place a resource under user authentication, you restrict access to it by requiring a name and password. This name and password is kept in a database on the server. This database can take many forms; Apache modules have been written to access flat-file databases, database management (DBM) file databases, mSQL databases (a freeware database), Oracle and Sybase databases, and more. This chapter covers only flat-file and DBM-format databases.

First, some basic configuration directives. The AuthName directive sets the authentication “realm” for the password-protected pages. The realm is what gets presented to clients when prompted for authentication, as in Please enter your name and password for the realm.

The AuthType directive sets the authentication type for the area. In HTTP/1.0, there’s only one authentication type—Basic. HTTP/1.1 will have a few more, such as MD5.

The AuthUserFile directive specifies the file that contains a list of names and passwords, one pair per line. The passwords are encrypted by simple UNIX crypt() routines. For example,


joe:D.W2yvlfjaJoo

mark:21slfoUYGksIe

The AuthGroupFile directive specifies the file that contains a list of groups and members of those groups, separated by spaces like this:


managers: joe mark

production: mark shelley paul

Finally, the require directive specifies what conditions need to be met for access to be granted. It can list only specified users who may connect, specify a group or list of groups of users who may connect, or say any valid user in the database is automatically granted access. The following is an example:


require user mark paul

 (Only mark and paul may access.)



require group managers

 (Only people in group managers may access.)



require valid-user

 (Anyone in the AuthUserFile database may access.)

The configuration file ends up looking something like this:


<Directory /www/htdocs/protected/>

AuthName Protected

AuthType basic

AuthUserFile /usr/local/etc/httpd/conf/users

<Limit GET POST>

require valid-user

</Limit>

</Directory>

If you want to protect a directory to a particular group, the configuration file looks something like the following:


<Directory /www/htdocs/protected/>

AuthName Protected

AuthType basic

AuthUserFile /usr/local/etc/httpd/conf/users

AuthGroupFile /usr/local/etc/httpd/conf/group

<Limit GET POST>

require group managers

</Limit>

</Directory>


Previous Table of Contents Next