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:

1. The user’s barcode is not registered in Aleph, so the user must visit the circulation desk.
2. 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.
3. The user has a fine of $5.00 or more.
4. 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.