Our library has several electronic resources that have stipulations on who may access that information. Some are restricted to Alumni, others to people on campus, and others to faculty and current students only. We wanted the system to recognize people without having them log in again, so that the resources would automatically populate in the pages based on their roles so that we could adhere to the stipulations. In order to do that, we utilized the CAS/LDAP plugin and read user roles from the LDAP. In addition, all of these resources are only available through the OCLC EZProxy software which meant that any resources that we added to our database needed to be listed in the EZProxy configuration file so that those resources would be available; this meant getting our WordPress data instance to write to a file on another server and restart the EZProxy service.
The data portion
First, I decided to get all the data we wanted to track into a plugin. This meant a way to update the e-resources themselves, the vendor list, and a means to create new categories and resource types. The plugin screens list each of the various lists and allow a means to edit each of them.
A standard format for listing:
A standard input format:
The presentation format
We didn’t want people to have to sign in again to view the electronic resources, even if they were coming from off campus. What we wanted was to limit the resources they could see based on their roles in the LDAP after they had authenticated against the CAS/SSO architecture. Once in, they would never see more resources than their physical location (IP address limitation) and user role (resource limitation) would allow. In order to display items in the database in a page with the electronic resources, we needed a means of limiting results from our data query and then posting those results into the page. We needed PHP code to do that, and a quick way to call the functions in our plugin was to use the “Allow PHP in Posts and Pages” plugin.
The functions in our plugin pulled data lists from the resources based on the criteria passed from the user log in and then presented links with a built in EZProxy URL. We utilized the EZProxy Ticketing system for this so that EZProxy would automatically trust the generated URLs and allow our users to gain access to the resources it protected.
EZProxy and WP sync
This one took a bit more thinking, as we had to basically write our data from our WordPress database into a file on another server and then restart the EZProxy service on that external server. Since it’s easier to deal with cron jobs as an existing user on a server, I decided that the easiest way to make the modifications happen was to have a “Sync Database to EZProxy” button on the EZProxy plugin page. That process would execute a shell script that writes a an EZProxy configuration file to a specific directory and then does an scp command to the same user’s home directory on the EZProxy server.
On the EZProxy side, there is another shell script that executes every fifteen minutes and checks to see if there is a new configuration file in the user’s home directory. If the file does not exist, the program terminates. If the file does exist, then the program renames the current configuration file to a backup with a timestamp and moves the file from the user’s home directory into the EZProxy directory and then restarts the service. Provided information wasn’t entered incorrectly on the electronic resource form, all the entries should work flawlessly on the EZProxy side and the service should restart without a hitch. If not, you’d be able to tell at :01, :16, :31: and :46 and call your helpful sysadmin to roll back to the old configuration file until you figured out what was causing the error.