A second user interaction: tables







Enter your name:

Enter your age:

Figure 15-10. A form laid out with table tags

#!/usr/bin/python
"""
runs on the server, reads form input, prints HTML;
URL http://server-name/cgi-bin/tutor4.py
"""
import cgi, sys
sys.stderr = sys.stdout              # errors to browser
form = cgi.FieldStorage()            # parse form data
print('Content-type: text/html\n')   # plus blank line
# class dummy:
#     def __init__(self, s): self.value = s
# form = {'user': dummy('bob'), 'age':dummy('10')}
html = """

Greetings


%s

%s

%s

"""
if not 'user' in form:
line1 = 'Who are you?'
else:
line1 = 'Hello, %s.' % form['user'].value
line2 = "You're talking to a %s server." % sys.platform
line3 = ""
if 'age' in form:
try:
line3 = "Your age squared is %d!" % (int(form['age'].value) ** 2)
except:
line3 = "Sorry, I can't compute %s ** 2." % form['age'].value
print(html % (line1, line2, line3))

Figure 15-11. Reply page generated by tutor4.py

Figure 15-12. Reply page from tutor4.py for parameters in URL

But you should never use
eval
to convert strings that were sent
over the Internet, like the
age
field in this example, unless you can be absolutely sure that the
string does not contain even potentially malicious code. For
instance, if this example were available on the general Internet,
it’s not impossible that someone could type a value into the
age
field (or append an
age
parameter to the URL) with a value
that invokes a system shell command. Given the appropriate context
and process permissions, when passed to
eval
, such a string might delete all the
files in your server script directory, or worse!

Unless you run CGI scripts in processes with limited
permissions and machine access, strings read off the Web can be
dangerous to run as code in CGI scripting. You should never pass
them to dynamic coding tools like
eval
and
exec
, or to tools that run arbitrary shell
commands such as
os.popen
and
os.system
, unless you can be sure
that they are safe. Always use simpler tools for numeric conversion
like
int
and
float
, which recognize only numbers, not
arbitrary Python code.

Error message trapping

This script assigns
sys.stderr
to
sys.stdout
so that Python
error messages wind up being displayed in the response page in
the browser. Normally, Python error messages are written to
stderr
, which generally
causes them to show up in the web server’s console window or
logfile. To route them to the browser, we must make
stderr
reference the same file object
as
stdout
(which is connected
to the browser in CGI scripts). If we don’t do this assignment,
Python errors, including program errors in our script, never
show up in the browser.

Test case mock-up

The
dummy
class
definition, commented out in this final version, was used to
debug the script before it was installed on the Net. Besides not
seeing
stderr
messages by
default, CGI scripts also assume an enclosing context that does
not exist if they are tested outside the CGI environment. For
instance, if run from the system command line, this script has
no form input data. Uncomment this code to test from the system
command line. The
dummy
class
masquerades as a parsed form field object, and
form
is assigned a dictionary
containing two form field objects. The net effect is that
form
will be plug-and-play
compatible with the result of a
cgi
.
Field
Storage
call. As usual in Python,
object interfaces, not datatypes, are all we must adhere
to.

Run the script from the command
line

It probably won’t generate HTML as is, but running it
standalone will detect any syntax errors in your code. Recall
that a Python command line can run source code files regardless
of their extension: for example,
python
somescript.cgi
works fine.

Assign
sys.stderr
to
sys.stdout
as early
as possible in your script

This will generally make the text of Python error messages
and stack dumps appear in your client browser when accessing the
script, instead of the web server’s console window or logs.
Short of wading through server logs or manual exception
handling, this may be the only way to see the text of error
messages after your script aborts.

Mock up inputs to simulate the enclosing CGI
context

For instance, define classes that mimic the CGI inputs
interface (as done with the
dummy
class in this script) to view
the script’s output for various test cases by running it from
the system command line.
^[
61
]
Setting environment variables to mimic form or URL
inputs sometimes helps, too (we’ll see how later in this
chapter).

Call utilities to display CGI context in the
browser

The CGI module includes utility
functions that send a formatted dump of CGI
environment variables and input values to the browser, to view
in a reply page. For instance,
cgi.print_form(form)
prints all the
input parameters sent from the client, and
cgi.test()
prints environment
variables, the form, the directory, and more. Sometimes this is
enough to resolve connection or input problems. We’ll use some
of these in the webmail case study in the next chapter.

Show exceptions you catch, print
tracebacks

If you catch an exception that Python raises, the Python
error message won’t be printed to
stderr
(that is normal behavior). In
such cases, it’s up to your script to display the exception’s
name and value in the response page; exception details are
available in the built-in
sys
module, from
sys.exc_info()
.
In addition, Python’s
traceback
module
can be used to manually generate stack traces on
your reply page for errors; tracebacks show source-code lines
active when an exception occurred. We’ll use this later in the
error page in PyMailCGI (
Chapter 16
).

Add debugging prints

You can always insert
tracing
print
statements in your code, just as in normal Python programs. Be
sure you print the content-type header line first, though, or
your prints may not show up on the reply page. In the worst
case, you can also generate debugging and trace messages by
opening and writing to a local text file on the server; provided
you access that file later, this avoids having to format the
trace messages according to HTML reply stream
conventions.

Run it live

Of course, once your script is at least half working, your
best bet is likely to start running it live on the server, with
real inputs coming from a browser. Running a server locally on
your machine, as we’re doing in this chapter, can help by making
changes go faster as you
test.