Even if you aren't administering a Web site that contains sensitive information (like the complete financial records of your company), you may still wish to restrict or control user access. For example, if you were running a subscription-based site, you'd only want those who've paid to be able to log on. Or, you may simply wish to require anyone who stops by to first "register" by filling out a questionnaire before they continue to surf.
A very simple level of user access control is to use nothing more than a reminder that a particular site has the following:
You can implement this with client-side scripting by hooking into the OnClick event handler of the browser, as demonstrated in the code fragment of listing 6.1.
Listing 6.1 Using OnClick to Control Access
<SCRIPT LANGUAGE="JavaScript">
<!--
function reminder() {
return confirm("The area you're about to enter " +
"uses advanced Web technology.\n" +
"Do you wish to continue?");
}
// -->
</SCRIPT>
...
<A HREF="webtricks/index.html"
ONCLICK="return reminder();">Advanced Web Tricks</A>
The OnClick event handler responds to a true or false value and either activates the link or not, depending on what the user selects.
| NOTE |
OnClick's ability to respond to true or false values is a new feature to Navigator 3.0. For Navigator 2.0 or Internet Explorer, the return value is ignored. |
If you want real security control with user names and passwords, the first step is to configure the Web server. This is done in two different ways. You can configure the server itself, or have an account on a major access provider to configure the directories of your site.
You're going to need a password file if you configure the server or just your own directories. This is often named .htpasswd. This is a flat-text file that contains user name/password pairs, one pair per line, for all authorized users. Individual lines in the file will resemble this:
sjwalter:Rin8y9njMYDQA
The first element is the user name, the second the encrypted password.
| CAUTION |
The password that displays is encrypted using an algorithm that makes it tough to decrypt. In fact, password checking in UNIX is done by accepting a password from the user, encrypting it, and comparing the encrypted forms. It is still possible to decipher these files by using what's commonly called the brute force technique. This technique involves the use of a program that keeps generating random words, encrypting them, and looking for a password match. It's not wise to make a password file too easy to decipher. |
Creating the password file is done automatically using a program such as htpasswd, which you run from the UNIX command line (via Telnet, for example).
Where you place the file isn't important but remembering where you put it is because you'll need that information later.
| NOTE |
The WindowsNT file system (NTFS) has access control built right in, allowing you to control who has access to a particular file (or directory) and the kind of access, such as read-only, read and write, execute, and so on, you permit. UNIX has similar abilities, called permissions, but you must be careful when restricting access under UNIX, because as far as the operating system is concerned, the Web server program is just another user. This makes it possible to restrict the access to a file to such a degree that even the server cannot read it. |
| TIP |
It's a good idea to enforce a "password lifespan" system on your server, where you require that passwords be changed on a regular basis, such as once a month. This helps to keep your system secure by not allowing accounts to use passwords for extended periods of time. The longer a particular password is valid on your system, the greater the chances of it being discovered. |
If you are running your own Web server, you can set up security by editing the server's control files. For example, the Apache server and the NCSA server (httpd) use a global access-control file usually called access.conf, which is typically located in the conf/ subdirectory below the actual server program. Other servers provide a graphical interface for access maintenance, either through the server software itself (as in the case of Web site by O'Reilly), or through a collection of HTML documents accessed by an ordinary browser (a method used by Netscape's FastTrack Server). Listing 6.2 shows an example access.conf file.
Listing 6.2 A Simple access.conf File
<Directory /var/httpd/htdocs>
AllowOverride All
AuthUserFile /var/httpd/.htpasswd
AuthGroupFile /dev/null
AuthName My Site
AuthType Basic
<Limit GET>
order allow,deny
allow from all
require validÐuser
</Limit>
</Directory>
| NOTE |
You're going to encounter the words "usually" and "typically" often when dealing with UNIX. Because of the flexibility of the system, it's quite common for individual administrators to customize their systems in a manner different from the default settings. |
At first glance, the file structure resembles HTML with opening and closing tags identifying different blocks, but this is not HTML. Rather, these pseudo-HTML commands are called sectioning directives because their job is to limit the scope of the commands within the body of the directive.
The Directory Directive The Directory directive indicates that the commands within its body only affects the specified directory. The one parameter it takes is an absolute path that identifies the particular directory. Inside the directive, several additional commands are allowed, including:
The Limit Directive Within the directory specified by <Directory>, the <Limit> directive permits you to control who has access and what access they have. Restrict access by:
domain name
IP address
individual user name
users as a group
Using the example from listing 6.2:
<Limit GET> order allow,deny allow from all require valid-user </Limit>
Access is available to anyone if they can supply a proper user name and password. You can find them in the file specified by AuthUserFile.
If your server allows for local overrides of the global access-control settings, as set by the AllowOverride directive, you create a secured subdirectory on your local site. This is especially useful for those who are using a commercial ISP instead of running their own server. Most ISPs configure their systems to permit you to create secure subtrees of your Web site.
| NOTE |
Being able to override the global access-control settings does not mean you can create and run CGI scripts locally within your Web directories. While your ISP is probably configured to allow you to override the password access to your Web site, chances are the override capability is limited to password settings. This is because allowing for local CGI scripts creates potential security holes within the system. |
To implement security for a specific directory, place a file similar to access.conf within that directory. Typically, this file is named .htaccess. The leading period prevents it from being seen with a casual directory list and, once placed within a directory, it specifies the access control for that directory and all subdirectories below it. An example .htaccess file that implements password access is shown in listing 6.3.
Listing 6.3 Example .htaccess file
AuthUserFile /var/htdocs/mysite/.htpasswd AuthGroupFile /dev/null AuthName My Site AuthType Basic <Limit GET> order allow,deny allow from all require validÐuser </Limit>
| NOTE |
The password file specified by AuthUserFile doesn't have to be in the same directory as .htaccess, but the path given must be an absolute path. If you have an account on an ISP, chances are when you log into your account via Telnet, you're automatically taken to your directory. This directory is not the root of the directory tree. |
Once you configure your site to limit access according to a password list, there are several different methods of presenting the log-in process to the user. They are:
Full source codes for each of these techniques is provided on the companion CD-ROM.
When the server recognizes that the browser is about to enter a secure area, it sends a request for user name/password authentication from the browser. Most browser's today display an "Enter Username and Password" dialog box similar to that shown in figure 6.1.
For the Web administrator, this requires the least amount of additional HTML coding because the only required task is the creation of the necessary password and access-control files that were covered earlier.
| CAUTION |
If you're going to implement security on your site, prepare for problems from your users. Specifically, browsers that support authentication also remember the user name and password for a particular site for the duration of the current browsing session. Some, like Internet Explorer, give the user the option to remember a user name/password combination permanently. This memory is confusing to some people who may register for your site, explore it, and then wander back out onto the Web for a while and return to your site before they quit the current session. As long as the browser didn't shut down, it remembers the first user name/password combination the user entered. They'll be let back into your site without being asked to log in. The confusion results from the next time the user launches the browser and comes to your site. This time, they will be asked for a user name/password. |
There are some browsers, however, that don't have authentication implemented. This makes access to a secure site under this technique almost impossible. One way, however, is to modify your log-in process to allow the user to fill out a form and log-in by submitting the form. One is shown in figure 6.2.
Form-oriented access control relies on the ability of CGI to redirect the user to a different URL using a given set of parameters or circumstances.
As mentioned earlier, some browsers permit the user to store a user name/password pair in a permanent list. The browser can then refer to it each time your site is visited, eliminating the user's need to log in each time. Not all browsers support this option. If you're setting up your site using a gateway form, password storage is a moot point.
A cookie in the user's browser can store the user name/password combination and make things easier on your users. Cookies are simple text strings that are stored in a file on the user's computer. Categorized by site and sub-categorized by the content designer, cookies allow Web designers to store user-specific information that can be accessed or changed each time the user revisits the site.
| NOTE |
One common use for cookies is to store configuration preferences for a particular user. For examples of this in action, see chapter 4, "Saving Configurations with Cookies." |
Because cookies are stored as a text file on the user's computer, it's not the safest place for sensitive data, such as passwords. However, if all you're interested in is keeping track of who's "registered" on your site, a cookie makes an easy way to identify people who have already gone through whatever process you specify.
This technique takes advantage of a derivative of the browser identification trick from chapter 1, "Browser Identification," and is shown here in listing 6.4.
Listing 6.4 User Identification through Cookies
#!/usr/local/bin/perl
if ($ENV{'HTTP COOKIE'}) {
foreach (split(/; /,$ENV{'HTTP_COOKIE'})) {
local($cookie,$value) = split(/=/);
$Cookies{$cookie} = $value;
$haveCookies = "1";
}
}
if ($haveCookies) {
if ($Cookies{'username'}) {
$htmlFile = 'member.html';
}
} else {
$htmlFile = 'visitor.html';
}
$htmlFile = join ("/", $ENV{'DOCUMENT ROOT'}, $htmlFile);
print "Content-Type: text/html\n\n";
open (HTML, "< $htmlFile");
print <HTML>;
close (HTML);
exit (0);
From inside CGI, any cookies associated with a document are passed in the HTTP_COOKIE environment variable. Each cookie is represented by a name and value pair, for example:
username=Scotty
with multiple cookies separated by semicolons:
username=Scotty;visits=15;favoriteColor=blue;
Listing 6.4 simply checks for the presence of a "user name" cookie, then loads the appropriate document using the Location header tag that instructs the server to redirect itself towards the specified file.
| TIP |
If all you intend to do is redirect the user to another document and not parse or modify the file before you present it to the user's browser, you can replace the last part of listing 6.4 that opens and prints the target file with: print "Location: $htmlFile\n\n"; Which instructs the server to request a totally new document. |
This chapter introduced you to the methods involved in controlling user access to your Web site. After making certain your server is properly configured, you can implement any of the scripting techniques discussed to actually log on. If you want to explore extensions to these tricks, check out: