Protecting individual files with the web server

Introduction to the Access Control List

The previous tutorials allowed protection of directories and directory trees by username and password or IP address or domain name, or a combination of the two.

It is occasionally useful to be able to restrict access on a file by file basis. This tutorial will discuss how that works. You have a lot of choice in protection schemes, by the way, and although this discussion is limited to using ACL's you don't have to choose between ACL's and the GET-Mask methods (discussed in the previous tutorials) for file protection, you can combine them or use them both. For purposes of clarity we will demonstrate just using the ACL to protect files and not introduce other variations.

To review the password file and its format and use, refer to the first tutorial . We will continue to use the user mott , whose password is blackberry , and the user dan , whose password is beachbum .

To do this, we have to introduce a new concept, the Access Control List . This is a file which contains 3 pieces of information:

File names to be protected, one or more.
Methods allowed on those files (GET or PUT)
The users or addresses who are allowed to access those files. If users are specified then the client will be prompted for a username and password. You can have a username and address combination just as with the GET-Mask directive.

If you're not certain what the "methods" mean here, GET means that the page can be retrieved, and PUT means that the user is allowed to execute CGI scripts. As an example, you might have a page which has a button for submitting some information. The page might be accessible for all users (via GET) but only qualified users can submit the request (via PUT). If you aren't sure what to do, specify both. The examples will specify both.

The access control list (ACL) file resides in the directory where you want to protect the individual files. Thus, you can have one ACL per directory. Each ACL can describe one, some, or all files in the directory. The file is always called www.acl .

The use of ACL's in the big scheme is pretty straightforward. There must still be a Protect directive in the configuration file which refers to the directory that you are trying to protect. If you are using usernames and passwords this must point to a password file. If you are using IP addresses or domain names it can be empty. The examples will show what the Protect directive looks like for each sample.

If there is a Protect directive for the directory in the configuration file and If there is a file called www.acl in the directory where the web server is looking for the file, then it will be consulted for protection information. If the file does not exist, no such consultation occurs.

Format of the ACL

The ACL has a pretty straightforward format. It is an ASCII file with one record per line, and as many lines as you want. Here is the layout. There are three fields separated by colons. You may remember that the password file is also a file which has fields separated by colons.

filespec: methods : users

As mentioned, the users can be either entries in the password file, or IP address, or domain names, or a comma separated list. The examples will illustrate the various permutations.

Introduction to the examples

In each of the examples we will show what goes in the SY:HTTPD.CON file and the contents of the WWW.ACL file. Remember, the WWW.ACL file goes in the directory that you are trying to issue file protection on, and you can have as many WWW.ACL files as you have directories with files in them that you want to protect. If they exist, they are used. If they don't exist then file level protection isn't performed.

Restricting access to one file in one directory to one user

This example will restrict access to the file test.htm in the /mott directory to the user mott .

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott

When an attempt is made to access this page the client will be prompted for a username and password. If it matches mott's entry in the password file, the page is returned.

Restricting access to two files in one directory to one user

Here we'll add another line to the www.acl file to show how to refer to more files.

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott
test2.htm: GET,POST : mott

Now the user mott can access either file, after a successful login.

Restricting access to all files in one directory to one user

In a sense this is a little redundant, since the GET-Mask rules allowed a way to do this, but this shows how to use wildcards in the file specs in the ACL file.

A better use of wildcards would be a filespec like abc*.htm , which restricts access to just those HTML files which begin with abc .

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat
}

In the \mott\www.acl file:
-----------------------

*.htm: GET,POST : mott

Now the user mott can access any HTML file, after a successful login.

Restricting access to one file in one directory to two users

This example will allow either dan or mott to access the test.htm file.

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott,dan

Once again we see a comma separated list, this time consisting of mott,dan . Either of those two are allowed access to the file.

Restricting access to two different files in one directory to two different users

This example will allow dan to access test2.htm and allow mott to access test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott
test2.htm: GET,POST : dan

Restricting access to one file in one directory to one IP address

As with the GET-Mask directive, you can restrict access to pages via IP addresses. This example restricts access to the test.htm file to any user at the IP address 123.123.123.009.

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : @123.123.123.009

Notice that we don't have to specify the name of the password file when we use just an IP address.

Restricting access to one file in one directory to multiple IP addresses

You can specify a list of IP addresses or use the wildcard character '*' to specify a range or block of IP addresses.

In this example, all users at all IP addresses 123.123.123.009 or 123.123.123.030 are allowed to access the file test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : @123.123.123.009,@123.123.123.030

In this example, all users at all IP addresses which begin with 123.123.123 are allowed to access the file test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : @123.123.123.*

Restricting access to different files in one directory to different IP addresses

As with different names, you can restrict access to different files to different IP addresses, either single addresses or lists or blocks. This example restricts access to test.htm to any user at address 123.123.123.009, and restricts access to test2.htm to any user at address 123.123.123.030.

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : @123.123.123.009
test2.htm: GET,POST : @123.123.123.030

Restricting access to domain names

Everything we've said about names and IP addresses also applies to the use of domain names. Remember, if you want to restrict access to certain domain names you must add the config option:

dnslookup On

in the SY:HTTPD.CON file. There is a performance penalty if you use this option, so you should avoid it if possible. In this example we restrict access to test.htm to any user from aol.com .

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : @aol.com

In this example we restrict access to test.htm to any user from aol.com or JPL at Nasa. Note the use of the '*' character as a wildcard in the domain name. This allows any user in any subdomain to access the file.

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : @aol.com,@*.jpl.nasa.gov

In this example we restrict access to test.htm to any used in any commercial (.com) domain names and restrict access to test2.htm to all users in Australia (.au).

 
In the SY:HTTPD.CON file:
-----------------------

Protect /mott/* {
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : @*.com
test2.htm: GET,POST : @*.au

Combining username and IP addresses or domain names

As with the GET-Mask , you can combine username and IP addresses and/or domain names to restrict access to someone from a certain address or domain and then requiring an additional login step. Note that the example has to refer to the password file, since the web server has to know where to find username information. In this example the user mott from IP address 123.123.123.030 is allowed to access test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

dnslookup On

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat	
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott@123.123.123.030

In this example the user mott from IP address block 123.123.123.* is allowed to access test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

dnslookup On

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat	
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott@123.123.123.*

In this example the user mott from IP address 123.123.123.009 OR 123.123.123.030 is allowed to access test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

dnslookup On

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat	
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott@123.123.123.009,mott@123.123.123.030

In this example the user mott from IP address 123.123.123.009 or the user dan from 123.123.123.030 is allowed to access test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

dnslookup On

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat	
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott@123.123.123.009,dan@123.123.123.030

In this example the user mott from IP address 123.123.123.009 is allowed to access test.htm . The user dan from 123.123.123.030 is allowed to access test2.htm .

 
In the SY:HTTPD.CON file:
-----------------------

dnslookup On

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat	
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott@123.123.123.009
test2.htm: GET,POST : dan@123.123.123.030

In this example the user mott from domain name sandh.com is allowed to access test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

dnslookup On

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat	
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott@sandh.com

In this example the users mott and dan from the domain name sandh.com are allowed to access test.htm .

 
In the SY:HTTPD.CON file:
-----------------------

dnslookup On

Protect /mott/* {
	PassWdfile  	/__c__/pwfile.dat	
}

In the \mott\www.acl file:
-----------------------

test.htm: GET,POST : mott@sandh.com,dan@sandh.com

Back to main