IT350 - Web and
Lab 9 – CGI with Perl
This week will be an
introduction to CGI programming. To do this, you will go back to the HTML form
you created for your website back in Lab 02/03, and finally put some
computation behind it – to really keep track of signups, orders, etc.
You originally created your
form in Lab02, though you should copy
your work from Lab03 (or later) instead, in order to benefit from your
later CSS additions. Recall that in Lab02 you were directed to create a form as
- Form: you must create a form for users to sign up for
something. This form may be on any page – index.html, schedule.html, or a
new page you create. Pick what
works best for your site. Specifics:
Your form collects necessary information from
the user such as name, rank, e-mail address, leave address, leave phone number,
new address, new phone number, seating preferences (table number), special
dietary requests, working party, course title, course number, sport, team name,
ingredients, directions, etc as appropriate for your topic.
Your form should contain at least one of
all of the following input types:
password (TIP: either assume the user has an
existing account or ask them to create a password to be used for possible
changes to their request later)
You must create a folder on you Web drive called
"Lab09" (without the quotes) and store your work in that directory.
the entire lab so you see the requirements and know what is coming.
first order of business is to write a basic Perl program and get that
working to the point where it produces some output visible with a browser.
We’ll walk you through this part:
- Right-click on submit and then save it in
W:\Lab09\submit.pl (you must
change “Save as type” to “All files”. Then change filename from submit.txt to
a look at submit.pl. Get a general
feel for what it does. (Note: it
has a few bugs that you will correct in a moment).
a Windows command prompt. To do
this, click on the “Start” button at the lower left corner of your
screen, pick “Run”, then type “cmd” and hit
the following into the window that appears:
perl –c -w submit.pl
(the –c says to only check the file, don’t run it. the -w says to
last step should identify a few errors in the program. Fix them. Re-run perl
from the command line until you get no more errors. (Hint: all control flow statements like if/while/for require
curly braces around their body – this is optional in most other
fetching the URL http://www.mXXXXXX.it350.cs.usna.edu/Lab09/submit.pl?name=Fred&age=72
You likely still have a logic bug or two in your
program that perl -w won’t catch. Fix the program so that fetching the
above link correctly produces the following output:
- Congratulations! You now have a working CGI program. You
will now modify it to use the values provided by your form.
should have a file form.html from Lab03, copied into Lab09. Make sure it satisfies the original
requirements for forms (given in the introduction above). Then modify the form (in your Lab09
directory) so that when you click submit, it invokes your new CGI
program. Modify your CGI program so
that it reads in some value from your form and displays the value in its
resultant HTML output.
check: Modify submit.pl
to validate some of the input
that your form provides to your CGI program. If an error is detected, your program
should state explicitly what the error was, and tell the user to hit the
back button and try again (see extra credit for a better approach). You
may find it useful to go back to Lab03/form.html, fill in some values, and
click submit to see how your data is received by the CGI program we gave
you earlier. For the validation you should at a minimum check the
following (you can of course do more if you like):
your first (or only) text field, ensure it is filled out (not empty)
your first (or only) text area, ensure it is filled out (not empty)
your first (or only) radio button set, ensure one radio button is
your first (or only) set of checkboxes, ensure at least one checkbox is
your first (or only) “select” box, ensure an option is chosen.
least one of your checks must involve a pattern match / regular expression
– e.g. to verify a phone number, SSN, etc. is valid. See section 25.3 of the book. You may also find the validation in
Figure 25.13 useful. You can
modify your form if you wish (to create a parameter that is more amenable
to validating with a pattern match).
Modify your Perl code so that, if the variables pass all the
validation tests above, the program prints out a user friendly
confirmation. This confirmation
should display the value of all the variables that were provided in
a user-friendly manner.
A page with a raw list of variables
and their values is not so friendly -- you should at least have a
reasonable title, some welcome text, then a reasonable confirmation of
their values. Imagine this was on your website and you wanted to present a
reasonable appearance to someone that just submitted your form. Example: “Your reservation for 4 people
has been confirmed. The details for
this reservation are as follows…”
check: Next you will modify your script so that one part of the user's
input, such as name, credit card number, etc, will be checked against a
list of fraudulent values stored in a file on the web server called
"fraud-values.txt". This file should be in your top level W:
directory – create a sample one that includes at least three different
values. Modify your script so that
it checks every submission against this file – you pick exactly which
field gets checked. If your script
finds a “fraud match”, the program should display a nasty message to the
user. You may need to change the permissions of fraud-values.txt to enable
the web server to read it.
Modify submit.pl so that it records activity to a file called LOG.txt.
You will want to append to this file (so it contains a history of
everything that has happened). To
enable this, first create the file (in your top level W: directory), then set its file permissions to
enable full access by the web server (see lecture slides). You should
write to the LOG as follows:
- If the values provided do not pass your
“Validity” tests above (e.g. that values are filled in appropriately),
write nothing to the log.
- If the values pass your “Validity”
test, but you detect a “Fraud match”, then write a single-line fraud
warning to LOG.txt (e.g. something like “Fraud detected for user
‘Syndrome’, reserving table for ‘4’.”)
- If the values pass your “Validity” test
and no fraud is detected, then write all the parameters provided by the
browser user to LOG.txt. The
values provided by a single user should all be on a single line – use a
vertical bar ( | ) as a separator.
Here’s an example of how a simple Log file might look after 4 users
submitted forms that passed the Validity test, where one triggered a
fraud alert :
ensure you have appropriate comments.
You are not required to
use Perl functions for this lab, since they will be covered later, but are
welcome to do so.
final step: create five links in your top-level default.htm page under
the heading “Lab09”
the name “Form”, make a link to your Lab09/form.html page
the name “Good submission” make a link to your
submit.pl file with all of form variables specified in the URL, such that
variables all validate and don’t trigger a fraud alert. Hint: if your form uses the GET method
(change this temporarily if necessary), then you can create the needed
URL for this by filling out your form correctly and hitting submit.
the name “Fraud submission” make a link like the one above, but such that
one of the variables triggers a fraud alert.
the name “LOG.txt” make a link to your log file
the name “fraud-values.txt” make a link to your fraud-values.txt file.
Your HTML web page
must be constructed using Notepad or a similar text-only editor. The use
of programs such as Microsoft Word, Microsoft Frontpage,
DreamWeaver, ColdFusion, Mozilla Composer, etc. will be considered an honor
For a nominal amount of extra credit do some/all of the
(NOTE: saving a backup copy of your working lab is recommended before starting
your program finds a validation problem with an input (such as a missing
value or a number that is too big), a much better way to handle this is to
have your CGI program regenerate the table with all of the values provided
by the user filled in, and values that had a problem highlighted. Of course there should be a submit
button so the user can modify the values and resubmit back to the CGI
a new CGI program (in Perl) that reads your LOG file and generates a
summary report of the submissions.
Be sure that your LOG.txt has enough data in it to make this report
at least a little interesting.
- Your main web page should be
called "form.html" (without the quotes).
- Your Perl file should be
- You should have all the
pieces working described in “Procedure” above.
- You should have the five
links in default.htm that are described above.
- All of your files should be
in a folder called "Lab09" (without the quotes) on the W drive. Your
instructor will assume that your web pages are viewable at http://www.mXXXXXX.it350.cs.usna.edu/Lab09/form.html
where XXXXXX is your alpha number. You may want to check that this URL is
viewable and that everything works correctly from a computer where somebody
else is logged in. If you've goofed and linked to a file on your X
drive, this will help you catch it!
- Turn in the following
hardcopy at the beginning of class on the due date, stapled together in
the following order (coversheet on top):
- A completed assignment
coversheet. Your comments will help us
improve the course.
- A printout of the
source to your submit.pl file.
Additional Hints/Clarifications (updated as the lab progresses)
are interesting because more than one can be checked. If you write
something like this:
the param() function will notice the result
should be an array (due to the @ symbol), and will return an array with
the values of all of the “mychecks” checkboxes
that were checked.
your code is not working, first run perl from
the command line (like you did in the beginning of the lab) to ensure
there are no syntax errors. Then,
add extra print() commands to see what parts of
the program are executing and what the values being used are.
book sometimes use the die() function to report errors. This is a bad idea for CGI programs
because the script will just terminate without sending the error message
to the browser. Instead, use
regular print() commands to send an error.