EZproxy wish list: Management API

EZproxy includes a management web site that allows for normal day-to-day operational tasks to be carried out with just a few clicks.  Need to setup SSL? No problem!  Need to review access logs?  They're right there.  Test network connectivity?  Click, click, done.  You can even test out new authentication settings prior to adding them to the configuration file.

There are a few areas where the interface falls short, though.

One area is with session handling.  We were working with session lifetimes, trying to find a good balance between having the patron re-authenticate and their proxy session lifetime.  That was when we discovered a bug where EZproxy resets the session timers for all sessions every time it is restarted.  Since we were changing the session lifetime values, we were restarting the proxy server more frequently than normal, and soon wound up with thousands of sessions that were considered active.

The admin interface to EZproxy would have you go to server status, click on each session, and click Terminate Session.  That's OK for a handful of sessions, but when you have hundreds of incoming sessions, trying to clean out stale sessions to keep the service up is like trying to drink from a fire hose.  I eventually wound up writing a data-scraping EZproxy management application to work around this.  It's not the most elegant solution, but it meets my needs to be able to script interaction with the proxy server.  Hopefully others find it useful as well.

It would have been easier to write that application, though, if EZproxy had an API that I could have tied into, rather than having to data-scrape the status page to load all of the sessions to enable terminating them one-by-one or en masse.  I originally did not want to do data-scraping, but the structure of the ezproxy.hst file is not documented, and is considered internal to EZproxy, thus subject to changing between versions.  The cleanest way to implement the tool was to go through the web interface and treat it as a management API.

Recently, I added the ability to execute Host Management commands to clear stale/unused entries in the proxy tables.  To add that support, I had to run strings against the EZproxy binary to find the embedded HTML page so that I could support all possible operations, not just the ones that were visible on my proxy server at the time I was developing the support.

Again, not an optimal approach, but a functional one, and now about the only thing that the management application does not support is SSL certificates.  I don't plan on adding that, but I can suggest certwatch as a utility that can be useful for keeping track of the SSL expiration dates.

Taking a step back, what I feel like I'm really asking for here is a little more of the Unix Philosophy be incorporated into EZproxy.  Break up the functionality a little bit, embrace modularity, separate the engine from the interface, decouple the act of management from the mechanism by which the management takes place, and open up the interface so that other tools can interoperate with the server.