Introduction
There are two basic modes of authentication for any database: by IP, where a user is allowed access if their IP number is within a prescribed range; and by "login", where the user is obliged to enter a valid Username/Password combination. Obviously, authentication by IP is to be preferred, since it offers transparency of access to the user; but there are times when this is not possible, either because the provider does not offer it, or more commonly because the user is outside of the nominated IP range. Authentication by login may be done through simple web server authentication, where the server responds to a request for a page in a secure area by requesting entry of a username and password, in which case the browser will prompt the user for these through a dialog box; or the remote site may use a cgi script to prompt the user directly for a username, password and perhaps other identifiers. The use of cgi scripts for authentication is ubiquitous, although the scripting language used varies considerably.
Where authentication is by login, we can sometimes provide a script to "do the login" automatically, in a way which is transparent to the user. This is the case with FirstSearch and Citadel databases (using OCLC's WebScript[1] program), which have been authenticated automatically for some time.[2] More recently, we have begun using scripted login for other databases, using a Perl[3] script written by the author. This is now in use for CSA and ABI, and possible but not yet implemented for IBSS. All of our login scripts are accessed from a secure part of our Web service, requiring entry of barcode/PIN.
Scripted Login with Perl
The Perl script is perhaps most easily described by an example:
#!/usr/local/bin/perl -w
# Scripted Login for www.resource.com
# Basic connection details ...
$host = 'www.resource.com';
$port = 80;
$path = '/cgi-bin/login';
$username = '*******';
$password = '*******';
# ... are used to construct a request ...
$content = "username=${username}&password=${password}";
# ... and finally the request message
$request= join "\r\n",
"POST $path HTTP/1.0",
"User-Agent: $ENV{HTTP_USER_AGENT}",
"Content-type: application/x-www-form-urlencoded",
"Content-length: ".length($content),
"",
$content,
"";
# Now make the request ...
($status, $http, $page) = &http_request($host,$port,$request);
# ... and relay the results to the user
unless (defined $http) {
print "Content-type: text/html\n\n";
print "<P>Unable to connect to $host/$path\n\n";
print "<P>Status received was: $status\n";
print "<P>Sorry!\n";
exit;
}
print "$http\n\n";
print qq|<BASE HREF="http://$host:$port$path">|;
print $page;
#End.
The script uses a library routine, http_request, to send the actual request to the remote server and return the response, which may be a bare status line (such as "connection timed out"), or some standard http status (e.g. "200 OK") followed by the http response header and some page data.
"$path" must be defined as the path to the remote login page, while "$content" must include all the input elements which would be returned after a normal login.
Assuming all has gone according to plan, the page returned will be the page that a user would normally see following a successful login. The script inserts a BASE tag before the page, in order to ensure that other elements referenced in the page with relative addressing (e.g. icons, links to other pages) will be addressed relative to the remote page, rather than relative to the local script.
Limitations
Scripted login essentially works by composing an http request containing the required Username/Password and sending that to the site, then returning the result to our user. The user does not get to see the Username/Password, only the "post login" page from the remote site. This approach is only possible for sites using standard CGI forms-based login. Sites using other methods for login, such as Web server (http) authentication, or login scripts based on Javascript, Java or Visual Basic (asp), cannot be scripted from our server by the current methods. One such site is ABIX, which is using VB to control their logins.
An additional complication arises when multiple logins are possible and required. For example, Current Contents login could be scripted, but we require different usernames for different departments. If the use of the login script is to be authenticated (and not merely used to bypass the remote site's authentication) then scripting Current Contents logon would require a level of complexity locally that we do not current support.[4]
A viable alternative to scripted login, where that is not possible, would be to provide a page containing the username/password, stored in a secure directory. The user would need to access that page to get the username/password, but would be locally authenticated first by Barcode/PIN. This approach is also useful when passwords change -- so long as the user returns to that page at regular intervals to check the login details.
References
[2] In the case of FirstSearch at least, the scripts were set up at a time when IP authentication was not possible; I believe they now offer IP authentication, but the scripts still work and are useful for users connecting from outside of our network.
[3]The Perl Programming Language, http://www.perl.com
[4]We'd need to be able to distinguish users by Department, which is not possible with the current authentication database, which only distinguishes staff from students, and library staff from others.
