Today, there are many options for processing forms on the server, such as ASP, PHP, and Java servlets. The traditional method is to use CGI scripts.
A CGI program (or script) can be written in a number of programming languages. It doesn't matter to the server which you use, as long as it can retrieve data and send data back. On Unix, the most popular language is Perl, but C, C++, Tcl, and Python are also used. On Windows, programmers write scripts in Visual Basic, Perl, and C/C++. On the Mac, AppleScript and C/C++ are common.
Often designers assume that the cgi-bin directory contains things beyond our comprehension. It's time to look behind the curtain! Although it is true that creating Perl and C scripts from scratch requires programming experience, you can still take advantage of the power of scripts by using one that is already made.
Many web-hosting services offer a library of standard CGI scripts that are already installed on their servers. In that case, all you may need to do is point to the script from your page. Some hosting providers also allow you to upload scripts of your own.
There are a number of great resources for CGI scripts on the Web, including scripts that process forms and send their contents in formatted email messages. Many of them are available for free and include exhaustive documentation that leads even a novice through the process of customizing and installing the script on the server. Some of the more popular CGI archives include:
A collection of free and useful scripts written by Matt Wright (including FormMail discussed later in this chapter) with excellent documentation for configuring. See http://www.worldwidemart.com/scripts/.
A complete index of over 1200 CGI-related resources. This site is compiled by Matt Wright of Matt's Script Archive. See http://www.cgi-resources.com.
"A public service website developed out of the late-night scripting expeditions of Selena Sol and Gunther Birznieks." See http://www.extropia.com/Scripts/.
Like the name says, this is another site providing useful and free customizable CGI scripts. See http://www.freescripts.com.
Because adding scripts and programs to your web site relies heavily on your server and its configuration, you'll need to work with your server administrator to get things set up. Before you start, you should ask your administrator the following questions:
Does your web site-hosting package include access to CGI scripts? Not all web site hosting services provide access to CGI scripts and functions.
Does the server have a script available that does what you're looking for? Many web site-hosting services have standard scripts available for their customers' use. If there's one already installed, it may save you some time in development.
Can you upload your own scripts to the server? Again, depending upon your arrangement for web site-hosting, you may not be permitted to upload your own scripts to the server, particularly if you are sharing a server with other sites.
Do you have upload privileges to the cgi-bin directory? Assuming you can upload your own scripts to the server, you need to make sure that you have write privileges to the directory where the scripts are stored (usually called cgi-bin). Your administrator may need to set up an account for you that gives you access to the directory and allows you to make your scripts readable and executable by other users.
On what kind of server is your site hosted? What server software is it running? Scripts are usually written to perform on a particular platform and web server software configuration. Before you spend time customizing a script, be sure that it can be run on your server.
What is the exact pathname to the script (once installed)? You will need to include this in the action setting in a <form>, or wherever you need to reference the script.
In addition, there will usually be a few questions specific to your chosen script that will need to be answered by your administrator. For instance, in order to run a Perl script, the basic Perl interpreter needs to be installed on the server. Or if you want a script that automatically takes the contents of a form and sends it in an email message, you may need to know the exact pathname of the sendmail program on the server (as we'll see in the following example). You will need to find out what names to use for the form elements, since the CGI program will be expecting forms to use certain names for specific data. You should also ask whether to use the post or get method for transmitting form information.
Let's take a look at the process for customizing a free script found on one of the CGI script archives. The purpose of this tutorial is to give you an idea of what to expect and to show that you don't need specific programming skills to do it.
In the following example, we use the FormMail script (written by Matt Wright), which takes the contents of a form and sends it to a specified user in a formatted email message. Although the script in its entirety (about nine book pages worth) is not shown here, you can easily download it from Matt's Script Archive (http://www.worldwidemart.com/scripts/ ).
First, make all the necessary arrangements with your server administrator as outlined in the previous section. You should have an understanding of how your particular server and account handle CGI scripts before proceeding.
Download the script. Upon downloading, you are given the script as well as a very complete ReadMe file that outlines, step by step, the process for using the script. Read the documentation carefully.
Configure the script. You may need to make changes within the script itself to customize it for your use. Following is a sample of the FormMail script. (Note that certain portions of this script have been omitted where indicated for purposes of fitting it in this chapter).
The FormMail program requires only three variables to be changed (highlighted in bold type in this example):
The pathname of the Perl interpreter on your server (in the first line of the script)
The pathname of your server's sendmail program (after $mailprog in the sample below)
The list of domains on which you will allow forms to reside and use your FormMail script (following @referers in the sample below).
These variables are clearly explained in the ReadMe file and are presented with labels in the beginning of the script for ease of customization. Furthermore, each section of the script is clearly labeled as to its function, if you are interested.
#!/usr/bin/perl ######################################################################## # FormMail Version 1.6 # # Copyright 1995-1997 Matt Wright mattw@worldwidemart.com # # Created 06/09/95 Last Modified 05/02/97 # # Matt's Script Archive, Inc.: http://www.worldwidemart.com/scripts/# ######################################################################## # COPYRIGHT NOTICE # # Copyright 1995-1997 Matthew M. Wright All Rights Reserved. # [full copyright notice omitted] ######################################################################## # Define Variables # # Detailed Information Found In README File. # # $mailprog defines the location of your sendmail program on your unix # # system. # $mailprog = '/usr/lib/sendmail'; # @referers allows forms to be located only on servers which are # # defined in this field. This security fix from the last version # # which allowed anyone on any server to use your FormMail script on # # their web site. # @referers = ('worldwidemart.com','206.31.72.203'); # Done # ######################################################################## [section omitted] sub check_url { # Localize the check_referer flag which determines if user is valid.# local($check_referer) = 0; # If a referring URL was specified, for each valid referer, make # # sure that a valid referring URL was passed to FormMail. # if ($ENV{'HTTP_REFERER'}) { foreach $referer (@referers) { if ($ENV{'HTTP_REFERER'} =~ m|https?://([^/]*)$referer|i) { $check_referer = 1; last; } } } else { $check_referer = 1; } # If the HTTP_REFERER was invalid, send back an error. # if ($check_referer != 1) { &error('bad_referer') } } [remaining script omitted]
Add mandatory controls to the form. The FormMail script relies on the following hidden input control, which must be included in the form. It tells the script who to mail the form results to.
<INPUT TYPE=hidden NAME="recipient" VALUE="email@your.host.com">
Add optional controls to the form. The FormMail documentation also provides a listing of other form controls you might include in your form and the exact HTML for creating them. The following is an example taken from the documentation that describes how to specify the "subject" field of an email message generated by the script:
subject
The subject field allows you to specify the subject you wish to appear in the email sent to you after this form has been filled out. If you do not have this option turned on, the script will default to a message subject: WWW Form Submission.
If you wish to choose what the subject is:
<INPUT TYPE=hidden NAME="subject" VALUE="Your Subject">
To allow the user to choose a subject:
<INPUT TYPE=text NAME="subject">
Upload the script to the correct directory, following the instructions of your server administrator. Be sure that you have included the proper pathname to the script with the action attribute in the <form> tag.
Copyright © 2002 O'Reilly & Associates. All rights reserved.