Last week, we gave you a couple of not-too-secure, but simple ways of hiding data on your Web site. This week, we'll get to the complicated part, installing real password protection, which gives your visitors really neat pop-up windows.
Why would you want to password protect your Web page?
In my case, I have a handful of files that I use, such as personal phone numbers, but don't particularly want to make public. There's others that I share with my editor, with my wife, Linda, and with a guy at the National Security Agency who will go unnamed at present (just a joke, folks, calm down). Using passwords, I can set who gets to look at what.
Now remember, this isn't industrial strength security. I wouldn't use it to protect medical records, accounting information or even hot photos. About all I have to worry about, though, is that someone might read an advance copy of my column and notice a) that I'm a lousy speller and b) that my editor writes most of the funny stuff.
The scheme we're addressing now works for most UNIX systems. You might check with your Internet service provider to find out whether it is allowable on your system, though low-level technicians won't always know how to help you. Note that this system does not work with the minority of Web providers using Microsoft Windows NT; you'll have to figure that one out for yourself, although Microsoft provides details at its Web site.
Otherwise, most Web servers support something called Basic Authentication. As we noted last week, you have read-write access to your Web directory, which the public can view via a standard Web browser, but not write to. Basic Authentication lets you block access to that directory, or any directories beneath it, until the person browsing provides an account name and associated password. You administer the names and passwords.
In the example we used last week, www/index.html is my home page, corresponding to http://www.li.net/dolinar It conceals the rest of the directory from public viewing, which would otherwise list the subdirectory "/topsecret." Thus no one knows that "/topsecret" exists, and hopefully, won't bother to look.
However, if they do know the name of the directory, they can walk right in and browse -- which means it's really not a very good form of security. Our project right now is to lock up that directory with a password.
There are two parts to creating a password-protected directory. First, you have to create a password file, which is a list of users and passwords that's set up by running a special program from the UNIX shell. Then, working with the UNIX shell or an FTP program, you install a permissions file in the directory you want to protect, naming the permitted users.
The permissions file locks out anyone who does not, when prompted, provide the account name that's in the permission file, and corresponding password that's contained in the password file. Your regular account security, i.e., your existing name and password, is what guards access to these security files. To get rid of security, just log into your account and delete the files.
Whew! Got that? There are some nuances here that took me about half a day to figure out myself, so don't be alarmed if you don't get it right away.
To start, let's assume you want to create an account for Dolinar with the password smartypants.
You log into your shell account, (In my case, I punch the Start button, select "run" then type in telnet li.net at the prompt). Once you're on the system, assuming you have a menu option for this, go into the UNIX operating system, indicated by a prompt that's usually just a dollar sign. You'll then run a command, htpasswd, to create the password file in the relevant directory.
In our example above, using my own directory structure, you type in the command as follows:
The system responds with:
Adding password for dolinar
You then type in "smartypants" after the colon, hit return, and you're prompted to retype the password to make sure you remember it. At this point, you will have created a file named ".htpasswd" in the directory "/dolinar." If you want, you can look at the contents of this file with any built-in UNIX editor, or somewhat simpler, log into your site with an FTP program and view the file. Note that we've put the file in a directory above the level -- "/topsecret" -- that we plan to protect.
There's going to be one line in the file, and it will look something like this:
The gobbledygook part of the line is your password, which has been encrypted for security.
Step two is to create the permissions file, ".htpassword," which is in plain text. You install a permissions file in any directory you wish to protect with a password. The permissions file contains the names of the legal users, and the location of the password file that contains their passwords.
The simplest way to do this is to compose the file in notepad, on your PC, and then upload it to the directory you wish to protect. If you make a mistake and accidentally lock yourself out of a directory, note that you can always use your FTP program to delete the permissions file, at which point password protection for that directory disappears.
Name the permissions file ".htpassword." It should contain the following lines:
require user dolinar
You can add as many names as you wish at the end. Each should be on a separate line, and follow the same form. i.e. require user tom, require user harry, etc.
A couple of traps exist here for the unwary. In the command htpasswd-c/export/users/disk1/dolinar/.htpasswd dolinar the -c option creates a new file. If you already have a password file, it will be overwritten by this new file. Unlike many password schemes, you don't need to know the old password to replace it with a new one -- you simply overwrite it. To add users to an existing password file, keep the same form as above, but omit the -c switch.
Another important thing to keep in mind: The permissions file does not have to include everyone who is in the password file. In other words, with the password file, you create a list of authorized users; the permissions file gives some or all of them access to a given directory. Thus, you can do as I have, and give your wife access to your personal phone numbers, but lock your editor out of them.
Remember you can have more than one permissions file as well -- located in any directory you wish to protect. You'll find a fuller description of password protecting Web sites at Apache Week (www.apacheweek.com/features/userauth) and at the National Center for Supercomputer Applications (hoohoo.ncsa.uiuc.edu/docs/tutorials/user.html)
Finally, remember that this type of security is merely OK, it isn't enough to keep out a serious hacker who's interested in you personally.
Next week we'll look at hit counters and a few other odds and ends for your Web page.
Dolinar can be reached by e-mail at firstname.lastname@example.org