Home » EZproxy
Category Archives: EZproxy
Changes to centrally-hosted EZproxy authentication
Recently, the Office of Library Services has made improvements to the way the centrally-hosted EZproxy servers handle authentication so that they restrict expired patrons from having access to electronic resources. This issue goes beyond a single group of patrons, such as high school students. This cuts across a variety of patron groups.
Centrally-hosted EZproxy authentication originally only checked whether a barcode was valid (i.e., the five-digit institution prefix). Subsequent improvements gave us the ability to check whether or not a patron had library privileges restricted due to overdue items or fines of $5 or more.
Until a couple of weeks ago, someone who graduated school or left their job at CUNY could have ongoing access to electronic resources for years. By remaining active in the Aleph catalog (e.g., with a minor fine), the patron’s barcode was deemed valid by the authentication process.
The recent changes to the way the centrally-hosted EZproxy servers authenticate users now allow us to also check the patron’s expiration date in his/her Aleph account.
Patrons that are loaded via the automated (CUNY-wide) batch loading process automatically receive global patron accounts. Barcode are needed for remote access to e-resources via the centrally-hosted EZproxy instances. Some libraries add them manually while others add them via a batch process.
Circulation staff are trained in-house about how to manually create local patron accounts. Depending on how staff set up these account, they can be given a variety of different privilege levels, including remote access to electronic resources.
For more details on new patron registration, please speak with your Access Services Librarian. If you have questions about patrons’ remote access to e-resources, please consult with your E-Resources Librarian.
Any remaining questions, please do not hesitate to contact OLS.
E-Resource Link Proxying in OneSearch
Proxying helps library users access commercially licensed e-resources off-campus, whether at home, on the road, or even standing on-campus but using a cell phone via the phone’s data plan.
We began by proxying some vendor links, but wanted a solution that allows easy batch proxying of links while also letting library staff control individual links.
OLS’s answer to this challenge is adding a special subfield to all links that need proxying: $xproxy.
For example:
85640 $uhttp://www.llmcdigital.org/default.aspx?redir=90010
$xproxy
$zAccess for CUNY Law School users
This achieves both goals. The subfield is not being used by Aleph, but it is valid cataloging, and lets OneSearch create proxied links on the fly. At the same time, proxied links are made school-specific. In other words, proxied links only display in OneSearch for the school that OWNs the record.
To support this, OLS has globally updated more than 250,000 licensed links in Aleph and OneSearch. In addition, new batch loads from specified vendors now receive the new $xproxy subfield.
Moving forward, control of OneSearch proxying is in the hands of each library.
In the future, when you identify records that need to be proxied and are not,
- many records: please provide a record number list or other way to uniquely identify the group and open a work order asking OLS to batch update the records
- individual records: simply add the $xproxy subfield to relevant 856 fields and save
For records that are proxied and should not be, do the opposite (remove the subfield individually or ask OLS to remove them).
FYI: It usually takes about 12 hours for changes in Aleph to be reflected in OneSearch.
Example of a OneSearch record with proxying, as seen at 2 schools:
- Graduate Center OneSearch (full text link proxied on-the-fly by $xproxy)
- Baruch College OneSearch (no full text link, so nothing to proxy)
For metadata fans, here is a look behind the scenes:
- vendor URL with CUNY ezproxy:http://law.ezproxy.cuny.edu:2048/login?url=http://www.heinonline.org/HOL/Page?handle=hein.beal/bltp0001&id=1&size=2&collection=beal&index=alpha/B_beal#3
- MARC in Aleph (Graduate Center record).
- OneSearch’s XML version of the record (we call this Primo Normalized XML, aka PNX). Check out those linktorsrc fields in the links section!
EZproxy and SIP: Update
This is an update on the recent trouble with the OLS-managed EZproxy servers. As far as we can tell, this was mostly an issue with the Queens College EZproxy instance. That particular instance sees the most usage of all our EZproxy servers.
We solved the problem by adding an additional authentication step that’s invisible to the user. It executes a script that validates the user’s barcode against the Aleph X-Server API.
So if a user’s barcode is at first rejected because the connection exceeds the SIP license limit, the second step is executed and the user has a “second chance” to authenticate.
We have examined our EZproxy log files to make sure that this is not an issue any longer.
Note that the most common problems with authentication are still:
- The user’s barcode is not registered in Aleph, so the user must visit the circulation desk.
- There’s a typo in the barcode (too many or not enough digits), or a different ID is used, or a search string is entered.
- The user has a fine of $5.00 or more.
- The user has a manual block.
If you encounter a barcode that doesn’t authenticate and you can’t figure out why, don’t hesitate to open a work order with the CUNY Service Desk.
Recent troubles with centrally-managed EZproxy servers
If you have a centrally-hosted EZproxy instance, you may have noticed an uptick in the number of users reporting authentication problems. This is due to our exceeding our SIP* license limit thanks to the increased use of e-resources (most likely stemming from OneSearch). We are looking into requesting a new SIP2 license from Ex Libris.
Because self-checkout also relies on SIP2, libraries with automated checkout machines may notice more users reporting problems with their barcodes there, too.
While we wait for the new license from the vendor, users experiencing problems with their barcodes should wait a few minutes before trying to re-connect to the database or checkout a book using a self-checkout station.
* The SIP server is used to query the Aleph patron file with the barcode.
How-To | User-triggered error reporting in EZproxy
In March 2013, while we were redesigning the EZproxy login pages for the proxy servers that we manage at OLS, I decided to spruce it up a little bit and make it so that users can send error reports if they reach needhost.htm:
