Getting the Username of Your Web Site Visitor

So far, you have been able to tell where the links to your Web site are originating from and to get information about the server where those links are connected.

Now let's look at the three environment variables that are supposed to contain the name of your Web site visitor: HTTP_IDENTD, HTTP_FROM, and REMOTE_USER.

First, let's deal with and then ignore the environment variable HTTP_IDENTD. This is a lousy means of confirming who is visiting your Web site. It only works if both the client and the server are running the IDENTD process. Even if the server is doing everything correctly, HTTP_IDENTD still can fail when you try to use this method, because you are dependent on the client's server also performing correctly. Even when everything works, the process requires extra communication between the server and the client, and that can really slow things down.

In the best of worlds, you are in charge of the server and you can turn on IDENTD yourself. But, more than likely, you are not the owner of the server and you would have to convince someone to turn on the IDENTD daemon. And you still must deal with the fact that your clients can come from any server in the world. There is no way you can force them to run IDENTD.

This all just seems like way too much work to me, so I suggest that you avoid the HTTP_REMOTE_IDENT environment variable as a solution to validating users. In the next chapter, you will learn how to set up basic user authentication using a username/password scheme. That methodology is much more reliable than the HTTP_REMOTE_IDENT environment variable.

So let's take a look at the last two environment variables: HTTP_FROM and REMOTE_USER.

HTTP_FROM is supposed to be set to the e-mail address of your Web site visitor. This has become an issue on the Net, though. People are afraid of unscrupulous Web sites getting their electronic name and address and selling it or using it for other commercial purposes. If junk e-mail isn't a problem for you yet, I'm betting it will be some time in the future.

So, to prevent themselves from getting a bad reputation, most browsers no longer support this feature. Or, if they do, they allow users to turn off this identification method. So, unfortunately for us, this environment variable is best used only as a default value for a return e-mail address.

Well, we are down to the last environment variable that can help us: the REMOTE_USER environment variable. Will this one tell you who is accessing your Web site? Yes-BUT, you won't like the way it is set. This environment variable is set only if an authentication scheme is being used between the browser and the server.

This isn't quite as hard as you might expect it to be. In order to set up user authorization, you need to set protections on your files or directories and create a password file for validated users. In Chapter 7 you will build an entire application that includes registering users, building a password file, and validating a user. So don't despair; I will cover how to do this in detail in the next chapter.

Unfortunately, I haven't given you any easy answers for how to get the name of someone visiting your site. It certainly is possible, and you can gather some information with existing environment variables. But in the long run, unless you want to validate every user, you are going to have to make do with less than you probably wanted to. At least now you have the full picture.

Using the Cookie

I have saved the dessert for last. The cookie, as it is fondly called, is one of the most powerful environment variables of the HTTP environment variables. I saved this variable for last for three reasons. First, it's only implemented for Netscape browsers. Second, it can really enhance your ability to treat a Web site visit as if a customer just entered your place of business. Third, it requires some detailed explanation.

One of the problems with building applications on the Internet is writing programs that remember what they were doing with customer X. When you cruise the Internet, each new link is a new connection to the server. It doesn't have any way of knowing what happened during the last connection. This means that each time your CGI program is invoked, you don't know what happened the last time.

Why do you care? Well, I expect online catalogs to be a major new programming application on the Internet, for example. But the first problem you run into is keeping track of what each customer is selecting for his purchases.

Imagine that you have three Web page customers at one time. Each of them is clicking on products, and your job is to keep track of who gets what. Just storing the data in a file isn't enough. If you have three customers, each making purchases, then you are going to need three separate files-one for each customer. How do you decide who is making the next purchase? Especially if they happen to be coming from the same server? Do you need to get the customer's name each time she makes a new selection? Yes! In some way, you must be able to separate your customers. Well, the Netscape cookie was built to help you solve that problem.

The Netscape cookie shows up in your environment variables only if the browser accessing your Web page is a Netscape browser. The environment variable is HTTP-Cookie, and it is a marvelous tool for maintaining state.

Remember that your browser sends a request header to your server, and then the server turns that request header into an environment variable. This means that after your CGI program sends the cookie to the browser, the browser is responsible for keeping track of it and returning it as a request header. So, each time your client submits one of your forms, you get a cookie that tells you which client it is.

Cookies are passed back and forth between the client and the server to identify a particular Web client. How does this chain of cookies get started?

When your Web site client first visits your Web page, he connects to your sever and probably requests your home page. Unless your home page is a CGI program, no cookies are exchanged yet. When your Web client submits to your CGI program the first time, no cookie exists. Your CGI program responds to the submittal with some type of Set-Cookie response header. You can generate a cookie based on the domain IP number and the current time. You then can send this cookie to the submitting browser as part of the normal response headers. This Set-Cookie response header might look like this: Set-Cookie: customer=$ENV{'HTTP_REMOTE_ADDR'} . $ENV{'DATE'};

This generates a unique cookie that the browser will send you the next time your Web client clicks on any Web page within your server root. You now can identify this client every time he accesses any Web page on your server root because the browser always will send this unique cookie, and your CGI program that previously saved the cookie can compare the cookie the browser sent with the saved cookie. The idea is that the requested URI will get only cookies that it knows how to interpret.

The Set-Cookie response header is made up of several fields. The format of the Netscape cookie is not very complex. The server sends to the browser a Set-Cookie response header. The only required field in the Set-Cookie response header is the name of the cookie and the value to assign to that cookie. So a valid Set-Cookie response header is Set-Cookie: customer=Jessica-Herrmann;

The Set-Cookie response header has several fields. Each field can be used only once per Set-Cookie response header. If you need to send more than one name=value pair back to the client browser, it is okay to send multiple Set-Cookie response headers in a single response header chain.

If all the fields of the Set-Cookie response header are used, the cookie looks like this: Set-Cookie: customer=Steve-Herrmann; expires=$ENV{'DATE'} + 2 HOURS ;   domain=www.practical-inet.com; path=/cgiguide ;

The semicolon (;) is used to separate the cookie fields.

The Name=Value Field

The Name=Value field is required and defines the uniqueness of a cookie to the browser. Don't be confused by this and the name/value pairs of forms. The name in this field should be set to a variable name that you will use in your CGI program-for example, customer or guide. The value probably will be based on something your customer submits. You can send only one name=value pair per Set-Cookie response header. You can send multiple Set-Cookie response headers, however.

The Name field is the only required field of the Set-Cookie request header.

The Expires=Date Field

The Expires=Date field is a command to the browser. It tells the browser to remember this cookie only until the expiration date given in the Expires field. When the expiration time is reached, the cookie is forgotten and is not sent to the server on any further connections.

This field is not required; if it is not set, the browser remembers the cookie throughout one Internet connection. So you can browse for hours, change Web pages, and return; as long as you don't close Netscape, it remembers your cookie.

The Domain=Domain_Name Field

The Domain=Domain_Name field should be set to the domain name of the server from where URI is fetched. So, if your form is submitted to www.practical-inet.com/cgiguide/chap6/test-cookie.cgi

the Domain field should be Domain=www.practical-inet.com

The Domain field is not required and defaults to the server that generated the Set-Cookie response header.

The Path=Path Field

The Path=Path field is used to limit the URIs with which the cookie can be used. So, if I want a cookie to match only if you stay in my chap6 directory, I can send a Set-Cookie request header with a path of /cgiguide/chap6.

The path is not required, and if it is not included, it is set to the path to the URI sending the Set-Cookie request header.

Returning the Cookie

When the browser is deciding which cookies to send with the request headers, it looks at the domain name it is accessing and matches all those cookies. Then, it looks at the URI and the path and matches any cookies that have a path matching the path of the URI.

This works because the match is from most general to specific. If the path is / or the server root, everything from the server root and below matches. If the path is /cgiguide/chap6/, everything in the Chapter 6directory and below is a path and URI match, and the browser is sent that cookie.

Think of a cookie as a ticket. A ticket is given each time your browser accesses a URI that sends a Set-Cookie response header. The ticket has information on it about who should get a copy of the ticket. The browser's job is to look at each ticket it has in memory each time it accesses a URI. If the information on the ticket says that this URI should get a copy of the ticket, the browser sends a copy along with its regular request headers.

Your code can look at the ticket and then determine from the Name=Value field to which customer the ticket belongs. Then you can go to the files that contain customer session information. Compare the cookie with the cookies in each file until you find a match. Or use the cookie to create a unique filename and get the correct file without performing a search.

Learning Perl

In this "Learning Perl" section, you will learn about managing files and some of Perl's more important special variables. You will use files throughout your CGI programs, so it's a good idea to have a strong foundation in dealing with files and filehandles. Later in this section, in "Using Perl's Special Variables," you'll learn about a group of special variables; these can make your coding task easier, but they also make your programming more cryptic. Use Perl's special variables as you need them, but use them with care.

Exercise 6.1. Using files with Perl

You've already seen several examples of reading and writing to files. During this exercise, you'll learn about some of Perl's built-in functions for manipulating files.

In the programming world, just like in any other profession, the experts seem to forget that they didn't understand everything when they started programming. I try not to be guilty of this, but I'm sure there are times when more explanation would be helpful. The goal of this exercise is to remove any barriers to understanding how a program reads and writes to files.

Let's start with the basic concepts of a filename-which also is referred to as a file variable-and a filehandle.

Understanding the Filename and Pathname

The filename is the actual name of the file your program is trying to read from your hard disk into computer memory or write from computer memory to your hard disk. If the file your program is trying to read from or write to can be in a different directory than the directory from which the program was started, you should supply the full path to the file in your program. The path to your file is called the pathname. The pathname to the file should start at the root directory. If you are using a UNIX platform, this means starting your pathname with a forward slash (/). If you are using a Windows/DOS platform, this usually means starting the path with the disk drive letter and then a backward slash (C:\).

On a UNIX platform, if you were reading a file from your home directory, it might be expressed as this: /export/home/usr/herrmann/input_data.txt

The filename is input_data.txt. The pathname is /export/home/usr/herrmann/. You can use this filename and pathname in your program store by just referencing it inside double quotation marks like this: "/export/home/usr/herrmann/input_data.txt"

I recommend that you save this pathname and filename to a variable for use throughout your program, as shown here: $inFile = "/export/home/usr/herrmann/input_data.txt";

The $inFile variable is referred to as a file variable. You can use either format to open a file for reading or writing. As far as Perl is concerned, they are exactly the same thing.

Understanding the Filehandle

The filehandle is not the same thing as a filename or a file variable. The filehandle has special meaning to the Perl interpreter; it is Perl's attempt to find the filename you passed to Perl using the open command. If Perl is successful at finding the file, it creates a special link to the file in computer memory. This link remains in effect until you use the close command on the filehandle or you use the same filehandle in another open command.

After you open a file, especially for writing, it is very important to close the filehandle when you are done working with the file. If you are writing to a file, its likely that all the data is not written to your file when your program executes the print or write statement. Writing to files or any input/output (I/O) operation is usually much slower than the speed of your CPU. Your operating system usually tries to help by collecting a group of file output operations before actually performing the output. This is called output buffering. Usually, the final contents of the output buffer are not written to the file until you close a filehandle. Emptying the output buffer by closing the file or by using some other means is called flushing the buffer.

Opening and Closing the File

Always remember to open a file before trying to read it. Doesn't that sound silly? Yet it's a common mistake to try to read a file without opening it. The computer doesn't have x-ray vision any more than you do. You can't read a guide until you've opened the cover, and a computer can't read a file until you open the file for it. The syntax for the open command is quite simple: open(FILEHANDLE,"filename");

The filename also can be a file variable. If you are using a filename, remember to use double quotation marks around the filename.

Closing a file is even easier than opening a file. The syntax of the close command is close(FILEHANDLE);

Exercise 6.2. Using filehandles

This exercise is a minor rewrite of Exercise 5.1, Using ARGV, to illustrate the use of filehandles. Take a careful look at the two programs; they produce identical results. Listing 6.12 contains the program you should type in for this exercise.

01: #!/usr/local/bin/perl
02: if ($#ARGV < 2)
03:    {
04:     print<<"end_tag";
05:
06: # $0 opens a file for reading and changes a name in the file
07: # use: $0 OLD_NAME NEW_NAME FILE_LIST
08: #      param 1 is the old value
09: #      param 2 is the new value
10: #      param +2 is file list. 
       There is no programatic limit to the number of files processed
11: # the original file will be copied into a .bak file
12: # the original file will be overwritten with the substitution
13: # the script assumes the file(s) to be modified are 
14: # in the directory that the script was started from
15: # SYMBOLIC LINKS are NOT followed
16: end_tag
17:     exit(1);
18:    }
19:
20: $OLD = shift; # dump arg(0)
21: $NEW = shift; # dump arg(1)
22: # now argv has just the file list in it.
23:
24: select(OUTFILE);
25: while (<>)
26:    {
27:     next if -l $ARGV; #skip this file if it is a sym link
28:     $count++ ;
29:     print STDOUT "." if (($count % 10) == 0);
30:
31:     if ($ARGV ne $oldargv) #have we saved this file ?
32:        {
33:        close(OUTFILE);
34:        print STDOUT "\nprocessing $ARGV ...";
35:        $count = 0 ;
36:        rename($ARGV, $ARGV . '.bak'); #mv the file to a backup copy
37:        $oldargv = $ARGV ;
38:        open (OUTFILE, ">$ARGV");# open the file for writing
39:        }
40:     s/$OLD/$NEW/go;# perform substitution
41:                    # o - only interpret the variables once
42:     print; #dump the file back into itself with changes
43:     }
44: close(OUTFILE);
45: select(STDOUT);