Much thanks for perl answers and a summary.

[laura hudson]

Thanks to all who answered my perl questions.  I received many helpful
replies and am now much more knowledgeable about what needs to be done.  I
also received many notes of commisseration from other librarians who have no
background in programming (any English majors out there?  Classics?) and are
scrambling to learn enough to make things like this work.  Thanks for that,
too--it's good to feel less alone.

And now for the summary.  I am assuming, I hope correctly, that none of you
will mind being quoted.

Question 1, about passing passwords to databases, is apparently something
many of you are interested in doing.  I will cut and paste some of the
answers I received:

My question itself:

> I have been asked to write a script which passes a password to a database so
> that we don't have to give the password to our users.  I know how to do this
> with a form button for a database such as GeoRef where the password
> interface is actually a Web page, but these databases seem to be using fmpro
> or some other database protection--a box pops up asking for a password.  Can
> this be scripted with CGI?  I find nothing about it out there.  The sites in
> question are the Harvard Educational Review (www.edreview.org) and the
> Directory of Electronic Journals, Newsletters, and Academic Discussions
> (www.arl.org:591/).

The answers (I quote only the unique answers--many more people wrote with
similar information):

*John Knight:
These sites might be asking for a username and password as part of their
web server's authentication mechanism.  One way "round" that for your
users would be to install a small proxy server for those services that
inserted the appropriate username and password into the HTTP protocol
stream and relayed the results to and from the user.  You could go this
fairly easily using a Perl CGI script (remember to parse the incoming HTML
from the remote servers to insert the URL of the proxy CGI script

*Albert Lunde:
This is an HTTP password. The only way I can think of to do it is
to write what is in effect a proxy server that re-writes traffic
going in both directions, adding headers to the user's requests
and removing headers from replies, and rewriting links.

One of our staff was working on something similar (not for
password authentication but IP authentication) and it took him
many months of work to develop.

The problem is that the password needs to be sent by the client
in the headers _with every request_. 

*A. Bullen:
This is going to be icky. Normally, you would just include in either the
HTML code:

<INPUT TYPE="HIDDEN" NAME="PASSWD" VALUE="<whatever the password is>">

or send it along as part of a calling cgi script:

print "<INPUT TYPE=\"HIDDEN\" NAME=\"PASSWD\" VALUE=\"<whatever the password
is>\">\n";

HOWEVER, what you're looking at is an .htaccess file that they have
installed on the
relevant subdirectory (a lazy way to do it, if I may say, because it robs
you of the
flexibility of being able to pass along the password as part of cgi call)
that looks
like:


<Directory /usr/local/httpd/htdocs/bakhome/LAKEBARR/Admin>
AuthUserFile /usr/local/httpd/etc/wwwpasswd
AuthGroupFile /dev/null
AuthName LAKEBARR
AuthType Basic

<Limit GET>
require user LAKEBARR
</Limit>
</Directory>


I am not sure that there is a way around having to fill in the forms. You
may ask
them nicely if there is a way that they could let you GIVE them a program
that you
write that allows you to pass the information that you need as part of a CGI
script
that would allow access to their data systems. You might also try and
investigate if
you can send it as part of the html header or as part of the ENV information
in a
CGI script. Just an idea...

*Bob Pasicznyuk:
If you want a program that passes user names and passwords, let me 
suggest the telecommunication scripts offered by OCLC in their automated 
login package.

They're easy to modify for other vendors.  They look at a given web site 
and pass information to it without the user seeing what's going on - 
similar to other telecommunications scripts in Procomm.  They're written 
in C.  All you need is a compiled binary and a text file that you modify 
with the site you want to work with.

If you're interested in this approach, send me a note and I'll correspond 
with you.

I put IPs in individually rather than the range method in your query.  
I'll have to look at your syntax to see what's going on.


Question 2 had to do with syntax in perl ranges.  I was doing it wrong and
received many helpful hints about how to do it right.  One of the many
helpful answers came from Jamie McCarthy:

"
>This line checks IP and it works:
>if ($user_ip =~
>/^132\.235\.\d*\.\d*|^198\.234\.69\.[241-254]|^198\.234\.122\.d*/){

It does the right thing for the wrong reason.  In a pattern match,
square brackets indicate a character class.  Each item in the brackets
is a single byte value, or a range of byte values.

So /123\.45[67]/ will match either the string "123.456" or "123.457".

And /12[357-9]/ will match "123", "125", "127", "128", or "129".

The thing in square brackets above, "[241-254]", will match any single
character which is either "2", "4", "1", "2", "5", or "4".  It happens
to be equivalent to "[1245]".

However, a pattern match does not match the whole string unless you
tell it to by putting "^" at beginning and "$" at the end.  You have
the "^" but no "$".  So the pattern as written can match any address
that begins "198.234.69." and whose next character is 1, 2, 4, or 5.

I think you meant to use parentheses instead of square brackets, and
to write something like this:


if ($user_ip =~
   /^
      (
         132\.235\.
      |
         198\.234\.69\.
            ( 24[1-9] | 25[0-4] )
      |
         198\.234\.122\.
      )
   /x)


The "x" after the trailing slash means you can put as much whitespace
in as you like, to make the formatting nice.  Very useful.  By
leaving off the trailing "$", you only need specify the first part of
the address (unless you want to syntax-check the rest of it to make
sure it's the correct format, of course).

I find that for regexs of any complexity, formatting them with
indenting like this is very helpful, if I'm going to want to come back
six months later and have a chance of understanding what they do.

Note that there's no easy way to match a numeric range in a regex --
you have to match each digit, which often means combining alternation
(the "|" character) with character classes (square brackets).
"

Laura Hudson
Alden Library Reference Department
Ohio University Libraries