NB: the absence of a remote URL does not imply that a resource
is unrestricted; it may mean that authentication and access control
is handled elsewhere, as in the following example:
https://www1.columbia.edu/sec-cgi-bin/cul/rlin/db?Eureka
Design aspects related to Stability and Performance
Earlier versions of the resolver stored proxied URLs but to increase
flexibility (including failover of proxy servers) the resolver
generates these URLs on the fly when it encounters a numeric token in
the remote URL field. As new remote access technologies are
introduced, the rewrite rules can be updated to accomodate them; in
our current implementation the proxy host name is read by the resolver
from an external file which allows an external script to monitor proxy
server availability and modify the content of this file as necessary.
Exceptions and special processing
VPN -- The resolver determines whether a user is on or off campus based on
the dns name of the computer running the browser. There are a number
of split tunnel VPNs however which need to be accomodated; browsers at
these addresses are directed as if they are off campus.
on campus proxying -- in some cases authentication to a remote resource is brokered by our ezproxy software; is these cases on campus users must be directed to the proxy server; this is accomodated by the use of the token "2". When the remote URL has a value of "2", a proxied URL is generated and all users are redirected to it.
Error handling, logging
If a non-existent key is passed to the resolver
http://www.columbia.edu/cgi-bin/cul/resolve?no-such-key
the user is directed to a generic error page. In addition, email to Systems staff is generated indicating the key as well as the page with the faulty resolver link (if any) for follow-up.
For each use of the resolver a log entry is generated. We log: time and date, resolver key, whether user is on campus (L), off campus (R), or has generated an error (E), the referring page, and url the resolver supplied.
Input, and update
There are four input streams into the resolver tables at present:
1 - a very small amount of manual inputting and editing is done for entries not associated
with cataloged material.
2 - we generate as needed, feeds from our LMS for bulk loaded records which is automatically loaded into the resolver; batch loaded
entries are flagged to trigger review of remote access settings.
3 - catalogers update the resolver via a web interface as material is cataloged.
4 - There is also an adhoc resolver entry form which accepts a URL, generates a unique key, and adds the key/url pair to the resolver. This is commonly used for document delivery as well as courseware
NB -- The resolver update procedures write to a flat text file which
is read and parsed in preference to the db file; this file is
periodically reviewed, edited as necessary and loaded into the
database.
Maintenance, querying and temporary redirection
We provide a series of online forms for library staff to interact with the resolver:
https://www1.columbia.edu/sec/cu/libraries/resolver/ner/resolver.html
Forms on this page allow librarians to :
query the resolver to determine the underlying URL associated with a key
report URL changes to Systems staff
temporarily redirect a resolver entry to a customized "out of service" page
restore a redirected service to its usual URL
The redirection mechanism is internal to the resolver code and does
not require updating of the resolver flat file or db file.
Before looking for a URL in its file/db the resolver checks a special
directory for a file with the same name as the key which was passed to
it. The existence of such a file indicates that the associated
resource is unavailable for some reason. The contents of this file, if
any, are interpolated into the text of an otherwise generic error
message indicating that the resource is unavailable. These files are
created, populated and removed directly by librarians without Systems
Office intervention. Transactions related to the creation and
deletion of these files are logged.
Specialized resolver variants
A special-purpose resolver for electronic reserves has also been
put into production. It differs primarily in that the user is presented
with a copyright confirmation dialog before being redirected to
the resource. A variety of specialized forms provide input into
this resolver:
https://www1.columbia.edu/sec/cu/libraries/resolver/voyres/voyres.html
|