Most people create web pages knowing they can be seen by anyone anywhere on the world wide web. This is a good thing. On the other hand, it's not uncommon to want only certain people to see certain pages, depending on their content. There are two ways to do this.
- WebAuth: This allows only Stanford people (all Stanford people, or just particular Stanford people, etc.) to see your web pages. WebAuth is the most often used method for protecting your pages at Stanford.
- User Authentication (this page): Lets you allow only non-Stanford people (or some combination of Stanford and non-Stanford people) to see your pages.
This tutorial supplies basic information you'll need to protect your pages with User Authentication
Controlling access at the file level
You need to protect your pages at the file level first. Web pages are, after all, just files in your AFS home directory. Since AFS is a distributed file system (it's on machines all over campus and the world), it's possible for anyone who knows AFS (at MIT, say, or Carnegie Mellon or Berkeley, etc.) to access the web files in your home directory and open them up to read them. To restrict access to the files in your web directory, just use AFS permissions to keep unwanted people out of that directory. Step by step instructions on how to do this are provided on the Setting Permissions pages. The crude basics:
- Log into Unix
- Go to your web directory
- Issue the following commands
fs setacl dir system:www-servers read
fs setacl dir system:anyuser none
Controlling access at the server level
In order to restrict access from web browsers, you will need to set up as many as three files depending on what type of access control you would like:
This file provides its directory with access control. Any web directory (which must be at or below the WWW directory level) whose access you would like to control must have this file. To protect all your web pages, put a .htaccess in your WWW directory.
Subdirectories of a directory with an .htaccess file will be under its control unless they have their own .htaccess file.
This file is necessary if you are using the "Basic" authentication method. Each line of this file pairs a user with an encrypted password.
This file allows you to assign sets of users to named groups.
Setting up your access control file
Sample .htaccess file
deny from all
allow from .stanford.edu
Access to the pages in this access file's directory is limited to users in the given password file (using "Basic" authentication), from machines within the Stanford domain. Note that it is the first three lines that restrict access for people while the last four restrict access for machines/networks. It is not necessary to have both sections in your access file.
Note: Always make sure your .htaccess file has a line return after the last line.
For User Athentication, where you're restricting people via the random usernames/passwords you've given to them, replace "type" with the word Basic. (If you were using WebAuth and restricting access by SUNet IDs/passwords, you'd have used the word WebAuth.
The symbolic name of this access file. It shows up when a user is prompted for a password. Specify whatever you think is appropriate. Only applies if you are using the Basic auth method.
(Basic) Specifies the absolute path of the user's password file.
(Basic) Specifies the absolute path of the user's group access file.
The following three access directives are used for domain protection - you'll always have order first, followed by the other two:
Specify allow,deny for "everyone but those" and deny,allow for "only these". Spaces aren't allowed next to the comma.
Specify either all, a domain name, or a host name.
Specify either all, a domain name, or a host name.
Only one directive controls which users are eligible for password verification: require. It takes one of these three forms (which are additive, i.e. a user gets the page if they satisfy any of the require lines:
require useruser1 user2 ...
Specify which users (separated by spaces) in the AuthUserFile file are allowed access upon providing a valid password.
require groupgroup1 group2 ...
Specify which groups of users in the AuthGroupFile are allowed access upon providing a valid password.
Allow all users in the AuthUserFile file access upon providing a valid password. (When used with the AuthType of WebAuth it allows any user who has provided a valid SUNet ID and password to see the file.)
Setting up your password file ("Basic" auth method)
These user names and passwords are not related to SUNet ID usernames and passwords. The passwords that you assign your users (or that they give themselves) should therefore not be SUNet ID passwords.
Run the htpasswd program to create your password file and to add users to it. For example:
htpasswd -c /afs/ir/users/y/o/yourname/.htpasswd user1
The program will then ask for user1's password and add it to the newly created password file. When you want to add another user, leave out the "-c" switch:
htpasswd /afs/ir/users/y/o/yourname/.htpasswd user2
Remember, the server will need read permission on the directory that has your .htpasswd file. You can put it outside your WWW directory to keep it from getting served as a web document, but the server still needs to be able to read it.
Setting up your group file
These groups are not related to AFS or Unix groups. They are just a convenience so that you don't have to provide long lists of users repeatedly.
Each line consists of a group name followed by a list of users. For example:
friends: clewis benr bpowell
co-workers: sisyphus clewis
For more information
See the Security Notes for information about protecting your password and group files.
See the WebAuth page for information protecting pages with SUNet IDs.
See Organizational Path Names for information about paths to your AFS home page.
Apache has detailed information on the directives used to control access.