HTTPd allows access restriction based on several criteria:
This tutorial is based heavily on work done by Ari Luotonen at CERN and Rob McCool at NCSA. In particular, Ari wrote the client-side code currently in Mosaic 2.0, and Rob wrote NCSA HTTPd 1.3.
General Information
There are two levels at which authentication information can be passed to the
server: the global access configuration file and the per-directory configuration
files. This tutorial covers per-directory configuration.
Per-directory configuration means that users with write access to part of the filesystem that is being served (the Document Tree) can control access to their files as they wish. Also, the per-directory configuration files are read and parsed by the server on each access, allowing run-time re-configuration. There is a speed penalty associated with using the per-directory configuration files, but that's the trade-off you have to take.
Access control for a given directory is controlled by a specific file in the
directory with a filename of .htaccess
Typically the .htaccess file contains access information
for a specific user or groups or users. The user given is
not
the userid of a user on the system, but is a user name you establish for
access
to your Web directory. In a typical application using .htaccess, the user
specified is paired with a password, also created by you. Password information
is stored in the .htpasswd file.
So two files, the .htaccess file and the .htpasswd file are normally required to implement simple Web directory security. Both these files must be given "world read and execute" permissions to work correctly.
So basically this method of authentication is roughly as safe as
telnet-style username and password security -- if you
trust your machine to be on the Internet, open to attempts to
telnet in by anyone who wants to try, then you have no
reason not to trust this method also.
So let's suppose you want to restrict files in a directory called
turkey to username pumpkin and password
pie. Here's what to do:
Create a file called .htaccess in directory turkey
that looks like this:
AuthUserFile /otherdir/.htpasswd AuthGroupFile /dev/null AuthName ByPassword AuthType Basic <Limit GET> require user pumpkin </Limit>
Note that the password file will be in another directory (/otherdir).
Be very careful about ending lines with a <return> immediately after
the characters on the line. Leave no trailing spaces or you're in big trouble!
AuthUserFile must be the full Unix pathname of the password file. So, if your home directory was /m3/webdocs/zoo, and you created a directory under it called animals that you wanted to define .htaccess rules on, and also wanted to store the .htpasswd file there, the first line would look like:
AuthUserFile /m3/webdocs/zoo/animals/.htpasswd
Also note that in this case there is no group file, so we specify /dev/null
(the standard Unix way to say "this file doesn't exist").
AuthName can be anything you want. The AuthName field
gives the Realm name for which the protection is provided. This name
is usually given when a browser prompts for a password, and is also usually
used by a browser in correlation with the URL to save the password information
you enter so that it can authenticate automatically on the next challenge.
Note: You should set this to something, otherwise it will default to
ByPassword, which is both non-descriptive and too common.
AuthType should be set to Basic, since we are using
Basic HTTP Authentication.
In this example, only the method GET (retrieving info from this area--applies
to Web pages)is restricted using the LIMIT directive. To limit
other methods (particularly in CGI directories), you can specify them separated
by spaces in the LIMIT directive. For example:
<LIMIT GET POST PUT> require user pumpkin </LIMIT>If you only use
GET protection for a CGI script, you may be finding that the REMOTE_USER environment variable is not getting set when using METHOD="POST", obviously because the directory isn't protected against POST.
Create the password file /otherdir/.htpasswd
The easiest way to do this is to use the webpasswd program at
the system $ prompt. You will need to be in the directory where you want
the .htpasswd file created. Supply the user you want to restrict access to
as the command line parameter. Remember, this is not a real system user
necessarily but any user name you like to access the information in
this directory--for example, "pumpkin".
webpasswd pumpkin
Type the password -- pie -- twice as instructed.
This will create the .htpasswd file in the directory from which you ran the webpasswd program. It will create the file if it doesn't exist or add user lines to it if it's already there.
Check the resulting file to get a warm feeling of self-satisfaction. You can
do this by typing cat .htpasswd (don't forget the period
in front--it's part of the file name!) at the $ prompt. It should look
something like this:
pumpkin:y1ia3tjWkhCK2
That's all. Now try to access a file in directory turkey
-- your browser should demand a username and password, and not give you
access to the file if you don't enter pumpkin and
pie. If you are using a browser that doesn't handle
authentication, you will not be able to access the document at all.
Add additional users to the directory's .htpasswd file.
Use the webpasswd command again with a new user.
Create a group file.
Call it /otherdir/.htgroup and have it look something
like this:
my-users: pumpkin peanuts almonds walnuts
... where pumpkin, peanuts,
almonds, and walnuts are the usernames.
Then modify the .htaccess file in the directory to look like
this:
AuthUserFile /otherdir/.htpasswd AuthGroupFile /otherdir/.htgroup AuthName ByPassword AuthType Basic <Limit GET> require group my-users </Limit>
Note that AuthGroupFile now points to your group file and
that group my-users (rather than individual user
pumpkin) is now required for access.
That's it. Now any user in group my-users can use
his/her individual username and password to gain access to directory
turkey.
fido with password
bones.
Important Note: There is no correspondence between
usernames and passwords on specific Unix systems (e.g. in an
/etc/passwd file) and usernames and passwords in the
authentication schemes we're discussing for use in the Web. As
illustrated in the examples, Web-based authentication uses
similar but wholly distinct password files; a user need
never have an actual account on a given Unix system in order to
be validated for access to files being served from that system
and protected with HTTP-based authentication.
rover with
password bacon and user jumpy with
password kibbles.
AuthUserFile /m3/webdocs/computing/INTERNET/examples/by-password-multiple-users/.htaccess AuthGroupFile /m3/webdocs/computing/INTERNET/examples/by-password-multiple-users/.htgroup AuthName ByPasswordMulti AuthType Basic <Limit GET> require group doggies </Limit;>
doggies:rover jumpy
ecst.csuchico.edu.
AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName notCSUChico
AuthType Basic
<Limit GET>
order deny,allow
deny from all
allow from ecst.csuchico.edu
</Limit>