ch6.htm

CGI programming is the hottest stuff to look out for in this book

the values to test different things (though that's a big factor),
it's that you're modifying the original script itself. Should
something happen where you forget to take out those values, you're
asking for problems. Or if the file is supposed to be read-only,
you'll have to keep changing the permissions on it back and forth.
Not a good scenario either way.
<H4>Wrapper Scripts</H4>
<P>
The next step up from hardcoded values is a wrapper script. As
most scripts will be reading data from environment variables,
the purpose of the wrapper script is to set those environment
values to some specific values. This means that you're no longer
going in and changing your primary script, which is a step in
the right direction.
<P>
There are two different types of wrapper scripts: ones where you
hardcode the values in them and ones where you don't. Out of the
two choices, the first is obviously easier because all you really
have to do is run something like the shell script shown in Listing
6.3.
<HR>
<BLOCKQUOTE>
<B>Listing 6.3. A sample shell script CGI wrapper.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">#!/bin/sh<BR>
set REQUEST_METHOD=GET<BR>
set QUERY_STRING=data+goes+here<BR>
script.pl</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
This gives you the ability to go ahead and set just the environment
variables you need. It then finishes by running your script. It
is small, easy to make, and effective. You could even redirect
the output of the script to a file, giving you a printable record
of what the program's output (and/or visible error messages) is.
<P>
Another method that is slightly more involved, but gives more
flexibility, is to build an interactive front end script for command
line testing. This would prompt you for each of the bits of data
that would normally be supplied, and also possibly include default
values so you didn't have to keep typing in repetitive data. It
would be much of the same process, but with a few additions here
and there. The following Perl script in Listing 6.4 is an example
of something of this type.
<HR>
<BLOCKQUOTE>
<B>Listing 6.4. Example of passing command-line values into a
CGI script.<BR>
</B>
</BLOCKQUOTE>
<BLOCKQUOTE>
<TT><FONT FACE="Courier">#!/bin/perl<BR>
# Generic Interactive command-line tester<BR>
print &quot;Enter a value for REQUEST_METHOD: \n&quot;;<BR>
chop($method=&lt;STDIN&gt;);<BR>
$ENV{'REQUEST_METHOD'}=$method;<BR>
print &quot;Enter a value for QUERY_STRING: \n&quot;;<BR>
chop($query=&lt;STDIN&gt;);<BR>
$ENV{'QUERY_STRING'}=$query;<BR>
exec &quot;script.pl&quot;;</FONT></TT>
</BLOCKQUOTE>
<HR>
<P>
You can add whatever environment variables you might want, depending
on what values you're looking for to evaluate within your program.
Regardless of the language of your actual CGI program, command
line wrappers can be in almost any language, as long as they can
set environment variables and execute another program.
<P>
Some other possible additions to a common line testing program
include modifications to allow placing input into STDIN, so that
a program that reads data from a POST method can function as it's
supposed to, and the ability to read all input from a file, so
that you don't have to type certain information in over and over
again, but output the results to a file with no difficulties.
<P>
<CENTER><TABLE BORDERCOLOR=#000000 BORDER=1 WIDTH=80%>
<TR><TD><B>Tip</B></TD></TR>
<TR><TD>
<BLOCKQUOTE>
Perl5, used in conjunction with the CGI.pm library, has the convenient ability to save you even that amount of effort. You can enter information right on the command line, with no wrapper script, and it'll understand what you're trying to do. For more 
information, see <TT><FONT FACE="Courier"><A HREF="http://www-genome.wi.mit.edu/ftp/pub/software/WWW/cgi_docs.html#debugging">http://www-genome.wi.mit.edu/ftp/pub/software/WWW/cgi_docs.html#debugging</A></FONT></TT>.
</BLOCKQUOTE>

</TD></TR>
</TABLE></CENTER>
<P>
<P>
What you're really checking for during command line testing is
the general category of problems-things that look out of place,
immediate errors, and other nastiness that jumps right out. Once
everything looks acceptable, and you can get the program to behave
in a manner you'd expect, you'll probably want to save the output
of your program into a file, so that you can compare it later.
This lets you know what the program was sending out before so
that you can see if this is the kind of thing that is happening
once you get it onto a server. This is your <I>baseline reference</I>.
<H2><A NAME="SolitaryConfinement"><FONT SIZE=5 COLOR=#FF0000>Solitary
Confinement</FONT></A></H2>
<P>
Once you have your baseline reference from command line testing,
you're ready to move onto a server, but not just any server. You
want to place the script in a location where you can safely go
wrong. Remember, you're in the testing phases and anything can
happen. For just that reason, you want something that meets the
following criteria:
<UL>
<LI><FONT COLOR=#000000>Prevents harm to original data</FONT>
<LI><FONT COLOR=#000000>Is not easily accessible to general users</FONT>
<LI><FONT COLOR=#000000>Is as close as possible to the server
it will be used on</FONT>
</UL>
<H3><A NAME="PreventingHarmtoOriginalData">Preventing Harm to
Original Data</A></H3>
<P>
Say your program reads in the log file and searches for a specific
line. With just one little error in a script, you can wipe out
the log, and lose all the data it contains. Whoops! To show you
just how easy it is, look at the following line of Perl code that
is supposed to open the log file:
<BLOCKQUOTE>
<TT><FONT FACE="Courier">open(LOGFILE,&quot;&gt;/httpds/logs/daily.log&quot;);</FONT></TT>
</BLOCKQUOTE>
<P>
The problem here is that the <TT><FONT FACE="Courier">&gt;</FONT></TT>
symbol means &quot;Write to the file,&quot; and, normally, to
create a new file to overwrite whatever was already there. Whether
or not it erases what was there, it's certainly opening the door
for data to get overwritten, or for the entire log file to get
corrupted. What the script really meant to say was:
<BLOCKQUOTE>
<TT><FONT FACE="Courier">open(LOGFILE,&quot;&lt;/httpds/logs/daily.log);</FONT></TT>
</BLOCKQUOTE>
<P>
It's the <TT><FONT FACE="Courier">&lt;</FONT></TT> symbol that
tells Perl to open a file for reading, not writing. Although you
probably won't have any errors like that in your code, it's always
possible. And if you're dealing with your online Web server, you
can't afford to take that chance. You might erase a configuration
file, or even lose some obscure but important data that will be
impossible to track down and replace.
<P>
There are a variety of ways to adjust where the files are being
drawn from, but sometimes it's impossible to get around the fact
that certain files that have to be in certain locations must be
accessed. In those cases, you should always make a copy of the
original. Even if it requires a lot of juggling to get the necessary
available space, do it. Think of how much of a pain it would be
to try and track down just what got changed without an original
to compare it to.
<H3><A NAME="IsNotEasilyAccessibletoGeneralUser">Is Not Easily
Accessible to General Users</A></H3>
<P>
What's the easiest way to keep people from getting to your script?
Why, just take the network cable and&#133;hold that thought right
there. Before you go and make what could be a horrible mistake,
review your options for isolating a server before yanking any
cables or doing something else equally as drastic.
<H4>Separation from the Network</H4>
<P>
Taking out the network cable from a Web server isolates it, but
it's going a little far. The computer is often very dependent
on other machines being connected to it, for a variety of reasons.
In addition, it might serve as a location for data that other
people internally access, and you'll be crippling their access
to what they need. If you're not experienced with networking machines
and the type your server is on, removing it completely from the
network isn't really the best option.
<P>
If you are experienced with networking, the type of computer the
server's on, and you know the whole possible slew of effects that
can cascade as a result of the machine being taken off the network,(perhaps
your Web server functions as your mail server, firewall, or NIS
server) you can certainly use that as an option. Even so, you
should be hesitant to do so.
<P>
If you can't physically pull the plug, what other methods are
there? Here are three options, in order of how easy they are to
use:
<UL>
<LI><FONT COLOR=#000000>Hide the script so that no one can find
it.</FONT>
<LI><FONT COLOR=#000000>Use the server's built-in security to
screen access.</FONT>
<LI><FONT COLOR=#000000>Create (or find) a similar server configuration.</FONT>
</UL>
<H4>Hiding the Script</H4>
<P>
Hiding the script is very easy and very commonly used. You place
the script in your cgi-bin directory and don't tell anyone about
it. You don't put big links to it from your home page saying &quot;Don't
click this. I'm testing a script.&quot; It might be convenient
for you, but who can resist clicking a link that says &quot;Don't
click this&#133;?&quot; Exactly.
<P>
The problem with hiding your script is that it's never really
hidden from all possible searchers. Search engines have this annoying
tendency-the page that you want to show up will never seem to
be there, but the ones that you least want people to know about
will pop up as big as life during a search. Isn't information
technology great? Although you can rely on this method for short-term
tests, don't leave it there for very long, or you risk the consequences.
<H4>Securing the Script</H4>
<P>
One of the most effective ways of protecting your script, and
one that's very easy to implement, is using built-in server security
to deny access to a particular script. Then it doesn't matter
who knows about your script; your server won't give people the
chance to do anything with it. Two common methods of security
permissions include a user/password scheme and general refusal
based on IP addresses. Out of the two, general refusal by IP address
is better for your use. If you have to keep typing in a user name
and a password to get at your script, you'll get very annoyed
with it very quickly.
<P>
Most servers have nice easy ways of setting these security levels-in
Process Software's Purveyor for NT, you can do it right from the
File Manager. If you're unfamiliar with how to do it with your
particular server software, or if it supports it, a quick browse
through the documentation should resolve both issues without too
much fuss.
<H4>Development Machine</H4>
<P>
The best of all possible worlds, though the least commonly available
method, is to have a development machine that is nearly identical
to the machine that users will be accessing. Many server software
packages come with a license to allow you to set the software
up on more than one machine for this purpose, and refer to one
as the Development Server and the other as a Production Server
or Live Server. If the server software you're using is freeware,
like NSCA HTTPD, then you can set it up on whatever machines you'd
care to.
<P>
Obtaining a machine that's similar in configuration might be a
tough job, but if you're doing something that could potentially
disrupt the system, it is less effort to dredge up a spare machine,
even temporarily, than to reconfigure your server machine.
<P>
After doing what you can to minimize who can get at your script
and what possible damage it can do, it's time to start the testing.
<H2><A NAME="LadiesandGentlemenStartYourTesting"><FONT SIZE=5 COLOR=#FF0000>Ladies