Magazine article Computers in Libraries

Testing the Off-Site Experience, or, How Well Do You Proxy? in the Simplest Sense, Specifying Appropriate IP Addresses Amounts to the Difference between Users Being Connected to the Full Text They Are Looking for or Being Asked for $40 for an Article

Magazine article Computers in Libraries

Testing the Off-Site Experience, or, How Well Do You Proxy? in the Simplest Sense, Specifying Appropriate IP Addresses Amounts to the Difference between Users Being Connected to the Full Text They Are Looking for or Being Asked for $40 for an Article

Article excerpt

Almost everything is now available online. That is a good thing in most circumstances because we are no longer limited to serving users within just physical spaces. This proves to be a wonderful benefit for users, but sometimes it doesn't always work out as expected. Those familiar with setting up electronic resources know the importance of specifying appropriate IP addresses with providers. What does this mean? In the simplest sense it amounts to the difference between users being connected to the full text they are looking for or being asked for $40 for an article. Your IP address is the piece of information that econtent providers are looking for when deciding whether or not to dish out full text, and it is well worth making sure that it can be found. In my experience as Brock University's digital services librarian, this amounts to configuring and, more importantly, testing your proxy server so that it connects to those resources.

The Need for Proxying The basics of the proxy are simple.

Essentially you have a piece of software that directs traffic coming in from off-site. It takes this traffic and redirects it to the requested resource on behalf of your remote user. Since that proxy server lives at your site, the resource sees a request from a recognized internet address and sends it along to the proxy server. The proxy server then passes it to the off-site user. Quite eloquently, your end users receive what they want with almost no knowledge of what happened. Only a small string of text needs to be added to the resource URL to wake up your proxy server so that it knows an off-site user needs to be connected. We use EZproxy at our institution, and this amounts to prepending the proxy URL before the resource URL.

We start with http://originalurl.com, and we end with http://proxy.library.edu/login?url=http://originalurl.com.

The proxy server asks the user for some credentials (a username and password, usually institutionally assigned), and the user is then linked to the full text. This seamless transaction is made possible by a list of addresses that the proxy server maintains internally. In essence, you have to explicitly tell the proxy server what resources you have access to (by means of a list of URLs); then it will be able to redirect your traffic. Things begin to go wrong when this list is not up-to-date.

Proxying Gone Wrong

Say, for example, a user clicks on a link in your OPAC that will take him to an ejournal. Let's say that the link is for The Canadian Journal of Zoology from the National Research Council. The OPAC link is the proxy stuff plus http://cjz.nrc.ca. The user clicks, logs in to the proxy, and is immediately taken to http://pubs.nrc-cnrc.gc.ca/rp-ps/journalDetail.jsp?lang=eng&jcode=cjz (notice the different domain names). If your proxy URL list only has the first address (cjz.nrc.ca), your remote user is out of luck. At this point the remote resource is no longer receiving traffic from the proxy server because this secondary site is not in the URL list. So your end user is left scratching his head. He has followed a link from your OPAC and logged in, but he still couldn't get to the resource.

It is of vital importance to check these proxy settings when creating access to new resources. These URL switches are more common than you would think and are the cause of a lot of headaches.

Easy Ways to Check Proxying

Most providers will give you a list of URLs to add to your proxy server but not always. So it is a good idea to educate users and staff about what the proxy does and why it is necessary. In my experience, many times a remote user contacts us to say that the full text for something is not available, when in fact it is and there was just a small problem with the proxy. The easiest way to make sure the proxy is doing what it is supposed to is by trying it out yourself. The problem is, if you are onsite, how can you test off-site access? …

Search by... Author
Show... All Results Primary Sources Peer-reviewed

Oops!

An unknown error has occurred. Please click the button below to reload the page. If the problem persists, please try again in a little while.