Automating CGI logons - clarification & further question

[Charles Blair]

> This sounds like what I need, but I can't find any documentation
> about "expect" -- is this an HTML tag, part of the CGI
> specification, or what?

None of the above. Do a Lycos search for "expect." Here's one result
(strong match):

---
3) Expect-5.13 [0.9673]

Outline: Expect-5.13 Environment Variables: Documentation

Abstract: "Cures those uncontrollable fits of interaction". Expect is
an extension to Tcl by Don Libes which allows you to use Tcl to
interact via scripts with other interactive programs. [...]
http://www.cs.ucsb.edu/Facilities/Software/expect.htm
---

Tcl is a scripting language like Perl. Anyone who's written a
Crosstalk or Kermit script (or the like) could make their way through
writing an expect script without knowing Tcl, though undoubtedly some
aspects of it will remain mysterious (you'll just take them on faith
and follow the "cookbook").

> Is there any way to do this with WWW servers that run a CGI script
> to ask for a name and password?  Do we need to set up a CGI script
> on our server to feed the info to the remote server? -- if so, how
> does this work?

Here is how we use it. Web page foo advertises an on-line service. The
anchor is something like:

<A HREF="telnet://proxy.x.edu:5013/"> ... </A>

The "telnet proxy server" is the machine that checks whether this is
an authorized request, i.e., coming from a machine on campus. (You
could also use .htaccess or the equivalent to protect the page
itself.) Port 5013 (the number is arbitrary, so long as it's high
enough that it won't be co-opted by a future canonical TCP/IP service)
is running a telnet daemon that forks the expect script. This means
that each telnet proxy service has an entry in /etc/services. Have I
said enough already?  That is, this is a job for a systems person
(whether from the computer center or the library). You must be very
careful not to create _BIG_ security holes on your systems doing this
(for example, you don't want a user breaking out and getting a
shell). So you want someone doing this who's security-conscious as
well (not just a good hacker).

The upside is that if you have a lot of these services, you can list
them on an internal staff web page, and your web authors simply pick
the URL for the service they want to advertise. Logons and passwords
remain secure and hidden: your telnet proxy server should be a machine
with restricted access, for example, open to systems administrators
only.

At our site we use a different machine for the telnet proxy server and
the web server, though that isn't necessary, provided you don't also
have regular users on the server (partly for load, but mainly for
security). Load so far has been minimal for the proxy server.