Password Protection
This form of access-restriction uses the built-in capabilities of HTTP, which is generally sufficient where the need for security is moderate (no acutely sensitive information is contained) ... though "moderate" and "sensitive" are matters of opinion and subject to much argument.
This technique utilizes built-in features of UNIX/Apache - when a user attempts to access a site in the restricted directory (or any subdirectory of it), a standard browser authentication dialog will appear, requesting the username and password to be entered in order to gain access.
Setting up HTTP restriction on a directory (and all subdirectories) is fairly straightforward: you'll need to create an upload two files (htaccess and htpasswd), and possibly a third (htgroup) if you need to manage an assortment of users and groups.
Worth mentioning: you also need to host with an ISP that will let you do this. Some ISPs don't allow this, as htaccess files can be misused or abused to do some things that can harm the stability or security of a server and they'd rather not deal with the consequences.
And of course, there are many subtleties I'm not addressing to cover the wide array of unusual things a person might want to do - this is just basic password protection, which will cover 99% of instances.
htaccess
The htaccess file (actually named .htaccess, with a leading period) is placed in the directory that you want to protect. It's content is:
AuthType Basic AuthName Name_of_Restricted_Area AuthUserFile /path/.htpasswd AuthGroupFile /path/.htgroup <Limit GET POST> require username1 require username2 require group groupname1 </Limit>
Breaking that down even further ...
AuthType Basic
Use this as-is. I'm aware there are other values for the AuthType (such as "digest") but I've never had occasion to use them.
AuthName Name_of_Restricted_Area
This is optional, but generally useful, in that the dialog that asks for the username/password generally displays this string to inform the user what he's logging into.
AuthUserFile /path/.htpasswd
This specifies the path (from the root) to the password file (discussed in the next section).
AuthGroupFile /path/.htgroup
This specifies the path (from the root) to the group file. If you don't need to maintain user groups, just omit it.
<Limit GET POST>
To be honest, I've always used this, as shown, without digging into details. On occasion, I've removed "post" on a directory if there were no executables.
require username1
Use these lines, as many as needed, to specify the usernames (corresponding to the htpasswd file) that must be entered to gain access to the directory. You can also place multiple usernames on a single line, separated by spaces, like this:
require user1 user2 user3
I've never used that technique - seems a bit cluttered and hard to maintain, but it will certainly save the bytes from having repeated "require" at the beginning of each line.
require group groupname1
This line will provide restriction by group, as named in the htgroup file (documented later). I expect the same alternative of using spaces can be used here, but again, I generally don't do that.
htpasswd
The htpasswd file (again .htpasswd, with a leading period) contains the names of the users and their passwords, like this:
user1:dL0GU02VpDZYE user2:o/1kJDAYWr3d2 user3:CRJj44r.st4xA
The user names are literal, but the passwords are encrypted to prevent anyone who accidentally gets hold of the file from being able to misuse passwords. (Actually, it's just a jerk hurdle, as decrypting passwords isn't that difficult once you've got the file.)
For that reason, it's a good idea to place htpasswd files in a directory that is not web-accessible (i.e., outside the document root), as low-rent miscreants can pretty easily find it and decrypt all the user's passwords.
As to how to encrypt passwords, that can be a bore, so I've developed a utility script to help: see it here.
htgroup
The htgroup file (again .htgroup, with a leading period) contains a list of groups and individual user names separated with spaces, thus:
groupname: user1 user2 user3 user4 user5
You will still need to use an htaccess file, as this contains only the user names. Also, the htgroup file doesn't contain anything that is much use to miscreants, but it's probably still a good idea to keep it out of the document root.
You don't
- Groups can be useful if you have multiple password-protected directories (you won't have to manage individual user names in separate htaccess files) - but then, my practice has been to have one directory and manage subdirectories' within it.
- They can also be useful if you have different types of user with different roles and corresponding permissions, such as readers, authors, editors, moderators and administrators to a content management system. But again, there are other ways to manage that using a subdirectory structure.
As of the time of this writing, I've been working the Web for almost twenty years, and have had less than a dozen occasions in which it was useful. But on those occasions, it came in very handy.
Notes and Contingencies
A few loose notes:
Using The Server Config File
Some sources suggest it's safer to set up directory access restrictions in the server configuration file (httpd.conf). That's certainly true, but I avoid it. Besides being a colossal pain in the sack, making a simple mistake in the server configuration file has the potential to do some serious damage (at the very least, bring your server down) and since you'll probably need to maintain user accounts fairly often, it's not worth the risk of having to continually hack the configuration file.
Nested Directories
The htaccess file in a subdirectory will override one in its parent directory, which can be used to create increasing levels of permission. It can also be used to create a public directory within a password-protected one, though this seems a bit goofy, it may be necessary to overcome mistakes in planning.
Multiple htpasswd/htgroup Files
For sanity's sake, it's often useful to have a single password and group file for a server, but it's not necessary. If you have distinct groups with no person being a member of both, it may be efficient to have multiple ones. The pain begins when you have one person who needs access to two or more directories, and needs to be maintained in multiple locations (or required to use different usernames and/or passwords for each. I reccommend being very certain this won't happen before resorting to multiple password/group files.