لطفا منتظر باشید ...
9.4 Using Email to Collect Form Data
It
is increasingly common to find authors who have no access to a web
server other than to upload their documents. Consequently, they have
no ability to create or manage CGI programs. In fact, some
Internet service providers (ISPs), particularly those hosting space
for hundreds or even thousands of sites, typically disable CGI
services to limit their servers' processing load or
as a security precaution.
If you are working with one of the many sites where you cannot get a
form processed to save your life, all is not lost: you can use a
mailto URL as the value of the form's
action attribute. The latest browsers
automatically email the various form parameters and values to the
address supplied in the URL. The recipient of the mail can then
process the form and take action accordingly.
By substituting the following for the <form>
tag in our previous example:
<form method=POST action="mailto:chuckandbill@oreilly.com"
enctype="text/plain"
onSubmit="window.alert('This form is being sent by email, even
though it may not appear that anything has happened...')">
the form data gets emailed to chuckandbill when
submitted by the user, not otherwise processed by a server. Notice,
too, that we have a simple JavaScript alert message that appears when
the browser gets ready to send out the form data. The alert tells the
user not to expect confirmation that the form data was sent (see
Figure 9-2).
Also, unless disabled by the user or if you omit the
method=POST attribute, the browser typically warns
users that they are about to send unencrypted (text/plain) and
thereby unsecured information over the network and gives them the
option to cancel the submission. Otherwise, the form is sent via
email without incident or notification.
Figure 9-2. A warning about a mailto form submission
The body of the resulting emailed form message looks something like
this:
name=Bill Kennedy
sex=M
income=Under $25,000
9.4.1 Problems with Email Forms
If you choose to use either mailto or a form-to-email facility, there
are several problems you may have to deal with:
Your forms won't work on browsers that
don't support a mailto URL as a form action.
Some browsers, including some early versions of Internet Explorer, do
not properly place the form data into the email message body and may
even open an email dialog box, confusing the user.
A mailto URL doesn't present users with a
confirmation page to assure them that their forms have been
processed. After executing the mailto form, the user is left looking
at the form, as if nothing had happened. (Use JavaScript to overcome
this dilemma with an onSubmit or
onClick event handler.) [Section 12.3.3]
Your data may arrive in a form that is difficult, if not impossible,
to read, unless you use a readable enctype, such
as text/plain.
You lose whatever
security protections may have
been provided by the server with the form.
The last problem deserves additional explanation. Some web providers
support secure web servers that attach an encryption key to your web
page when sent to the user's browser. The popular
browsers use that key to encrypt any data your document may send back
to that same server, including the user's form data.
Since only the client's browser and the server know
the key, only that server is able to decipher the information coming
back to it from the client browser, effectively securing the
information from nefarious eavesdroppers and hackers.
However, if you use email to retrieve the form data, the server
decrypts it before packaging the form information into the body of an
email message and sending it to you. Email normally is highly
susceptible to eavesdropping and other types of snooping. Its
contents are very insecure.
So, please, if you use an email method to retrieve sensitive form
data, such as credit cards and personal information, be aware of the
potential consequences. And don't be fooled or fool
your users with a "secure" server
when insecure email comes out the back end.
In spite of all these problems, email forms present an attractive
alternative to the web author constrained by a restricted server. Our
advice: use CGI scripts if at all possible and fall back on mailto
URLs if all else fails.
