Tcl/Expect CGI example

This project is a CGI program written in Tcl which makes use of the 
capabilities of the Expect application.  Expect is a Unix utility
which is an extension of the Tcl shell/interpreter.

For more information about the Tcl shell/interpreter:
 The Tcl Platform Company 
 TCL WWW Info

overview:

I felt this project would be a good exercise for myself and a 
useful resource for the class archive.  It provides an example of
how a CGI script can incorporate an interactive session, such as a 
telnet session.  This could be needed when the CGI needs to access
an application that exists on a system which does not support a web 
server.  The CGI can be run on one machine and actually log in to 
the remote machine to execute its functions, then return to the user.

Unfortunately, Tcl is available on shrike, but Expect is not. So I
was not able to provide an working example on shrike for you to try,
just sample code and output.

It is somewhat based off of a script i created at work to automate
a task that i had been doing frequently.  I generalized everything
a bit to take out proprietary references and to hopefully provide 
an example simple enough to be easily modified if someone in class
wanted to try basing their own application off it.   Obviously,
the commands i provided to execute from the form are very generic
and probably would not be used for a real application.  These 
commands would be replaced with the one or more specific commands 
needed to perform the necessary task.  Also, depending on the
application, you may want to implement the commands directly within 
the script and not give the user an option to choose among several
commands in an HTML form.  That is how my original CGI worked. 

background:

The scenario i initially implemented was that i wanted to view a 
system test script that was stored in a Test Management System on a 
remote machine.  Inspired by what i learned in our first assignment 
in class this quarter, the CGI assignment, my plan was to create a 
simple HTML form where i could plug in the test id and have a CGI script 
get the test for me.  I started out planning to just use basic Tcl, 
but ran into some roadblocks and found that the Tcl extension Expect 
provided just the functionality i could use.

The test scripts are written using Unix troff formatting, and 
there are many tools which exist to print the formatted scripts 
to the terminal or to a printer, but certain tables and other
formatting functions would not display well in a browser.  I found
i needed a several step process to get the scripts to display.
After getting to the remote machine, first query the database for
the test script and save to a file.  Second, run a tool on the file
that will convert the unix formatted files to HTML.  Finally, display
the HTML file to the browser and cleanup the temporary file on the
remote system.

Expect was developed to handle this exact situation, automation of
an interactive session.  It allowed me spawn a telnet session and 
keep the session up until i had executed all the needed actions and 
verify that i saw expected responses.

This work was done mostly as an exercise to get myself familiar with 
programming with Tcl which i will need to be familiar with for a
project at work.  But also to automate a task i was often repeating 
and to try to apply some of what i learned in class.  Of course, 
a couple days after i finished i found out that the database team
ALREADY had a web interface available to provide the functionality 
i was looking for.....


security issues:

One of the main security issues with Expect is in regard to the
handling of passwords.  Generally, if a script is working with a
program like telnet, ftp, etc... it will need to know the password
of the remote machine.  Most scripts have the password hardcoded
within for simplicity, and effort must be made to keep the script
secure.  The preferred programming style is run the scripts from
a secured host that would prevent users who should not read the
script from even logging in.  I think an alternative style would 
be to send the login and password to the script as parameters in 
an encrypted QUERY_STRING. 

Inspired by these security issues and by the seminar regarding 
Secure_HTTP, i did do some digging and i was able to implement 
some additional security.  I did some searching and was able to 
eventually find a login mechanism that is available on systems
using a Netscape Enterprise webserver.  A simple procedure is 
provided that will control access to a particular directory which 
you can specify.  Basically, before allowing access to this directory,
Netscape brings up a login  window  and the user must authenticate
to the program.  The directory has its own password file.  So in
this way you can control who is able to run the CGI. The steps to 
set this up were very straightforward.  

View the Netscape  security info 


Sample form.html

View the CGI source code

View sample output 

 example 1 
 example 2