The previous chapter introduces some tricks for validating the data entered by a user within a form. Now that the information has been verified, what do you do with it? As an open-ended question, this depends greatly on the intent of the particular form, but there are several common things that Web designers want to do with form data.
Web browsers have built-in support for interfacing e-mail addresses into HTML pages. Within a hyperlink, you can force the user's mailer to be launched automatically simply by using the mailto: protocol:
mailto:sjwalter@visi.com
However, for various reasons, this may not be the most ideal system. Specifically, mailto: doesn't give you explicit control over the structure of the e-mail sent; for example, creating a specific subject line, if you're running a mail script that scans for such lines. While Netscape has made some extensions to the mailto: protocol permitting you to pass additional information to the mail client, they are not considered part of the standard (only Netscape browsers support them).
You can still get the level of control you desire by designing an HTML form to serve as the front-end to the mail system, then having a Perl script do the work of formatting and sending the e-mail the way you want. Additionally, using form-based e-mail permits you to seamlessly integrate mail handling into your site (as shown in fig. 14.1), without having to bother the user with additional programs-in this case, their mailer-being launched.
You can pass "parameters" from within a form by taking advantage of the HIDDEN object type within the form's definition. Hidden objects are identical to TEXT objects, except that they aren't formatted for display, giving you a storage space within the form structure for additional text that can be used to customize a generic mail processing script to the particulars of your form.
For example, if you were constructing a "help-desk" form, where a user can pose a question to you, you would want the three following fields:
Additionally, you would want to specify the following fields, but with predetermined (non-user editable) values:
These two fields are then ideal candidates for hidden fields. Listing 14.1 presents an HTML fragment that outlines a <FORM> tag formatted to the above requirements.
Listing 14.1 Using Hidden Fields for Parameters
<FORM METHOD=POST ACTION="/cgi-bin/e-mail.cgi"> <INPUT TYPE=HIDDEN NAME="sendto" VALUE="sjwalter@visi.com"> <INPUT TYPE=HIDDEN NAME="subject" VALUE="Help!!!!!"> Your name: <INPUT TYPE=TEXT NAME="realname" SIZE=40> Your e-mail address: <INPUT TYPE=TEXT NAME="e-mail" SIZE=40> <P> Please describe your problem:<BR> <TEXTAREA TYPE=TEXT NAME="problem" WRAP COLS=60 ROWS=15> </TEXTAREA> <INPUT TYPE=SUBMIT NAME="submit" VALUE="Submit Problem"> <INPUT TYPE=RESET NAME="reset" VALUE=" Clear "> </FORM>
CAUTION |
It is mentioned in other chapters that caution should be taken when designing script processing that relies on the input from a user. If the data the user enters is going to be treated, at any time, as data to process (for example, embedding HTML tags within a comment block for formatting on a graffiti wall), it's critical that you take steps to ensure that the user can't enter any script-level commands that would change the manner of processing. If this were to happen, the user could potentially gain access to your system in an undesirable way. Hidden form fields can be as dangerous depending on how the field is to be processed, as a "savvy" user can simply download your form page to his or her machine, edit it locally, and then run the local copy (complete with edited fields) that your server would treat just as though it were your own form page. To circumvent this, make certain that any hidden fields you specify deal with information that doesn't generate disastrous side effects if the data is modified, such as specifying paths within your system for reading and writing files. |
One major advantage of implementing parameters within the form is that it allows you, the Web administrator, to install a generic form-to-e-mail script that all your users can utilize within their own pages. In this way you can offer form processing as a service without having to give users access to the CGI directories.
Once the user has clicked the Submit button, all data, including hidden fields, is transmitted to the server for processing by the CGI script.
The standard Perl technique for loading values from form fields applies to mail forwarding as it does for any form processing. Simply retrieve the contents of the CONTENT_LENGTH environment variable and split it into the individual fields name/value pairs (as shown in listing 14.2).
Listing 14.2 Creating a Named List of Form Fields
read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
@pairs = split(/&/, $buffer);
foreach $pair (@pairs) {
($name, $value) = split(/=/, $pair, 2);
$value =~ tr/+/ /;
$value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
$contents{$name} = $value;
}
Remember that spaces within field values are converted into plus signs (+) before they're transmitted back to the server. Therefore, it's necessary to convert them back to spaces. Additionally, special characters are often %-encoded for transmission, so converting them back is also necessary.
With the fields now in memory for processing, it's time to fire up the mail program and send the e-mail on its way.
Sendmail is by far the most commonly used mail agent among UNIX systems today. It is powerful and highly configurable. In fact, rather thick texts have been written dealing with nothing but its installation and maintenance. The beauty of this program is that it can take data from standard input and treat it as if it's a mail message to process-as long as the data is in the correct format.
The general format for e-mail when dealing with sendmail is:
| NOTE |
Most information thrown around in "Internet format" uses the header-blank-body structure. The blank line between header and body is critical. Without it, sendmail or the Web server doesn't know when to stop processing directives and start treating input as content. |
Sendmail is run in "standard input mode" by including the -t parameter on its command line. From Perl, this is handled by including the parameter as part of the open() command:
open(MAIL,"|sendmail -t");
which opens up a file handle MAIL that's hooked into sendmail's input. Normally, you'll want to specify the complete path to the location of the sendmail program in order to ensure that it's found and able to run when needed.
With the "file" opened, regular Perl print commands can be used to send the e-mail to sendmail (as shown in listing 14.3).
Listing 14.3 Sending Mail
print MAIL, "To: $contents{'sendto'}\n";
print MAIL, "From: $contents{'e-mail'}\n";
print MAIL, "Subject: $contents{'subject'}\n\n";
print MAIL, $contents{'problem'}\n"
Because the Subject: line is the last line of the mail header in this example, the addition of a second newline character (\n) forces the blank line separating header from body.
Closing the file handle with the Perl close() statment completes the message stream and lets sendmail start the process of directing the e-mail to its proper destination.
This is an example of a very basic mail handling script. Many of the scripts are freely available on the Web, some of which you'll find on the companion CD-ROM. They have many more features, such as:
Sends a customized "your e-mail has been sent" document back to the user.
Includes additional information about the browser, such as the type of program, operating system, and so on within the body of the mail message.
Allows the users to request that a copy of the e-mail sent be forwarded back to their mail accounts for their own records.
Tests the validity of the e-mail address destination.
Tests the validity of any of the fields to make sure that someone doesn't waste your time by sending an empty message, or one that's missing critical data.
The amount of flexibility you want to implement is up to you.
This chapter takes a brief look at the process of integrating a mail system into your Web pages. For related topics, check out: