EZproxy wish list: Structured configuration file

A common point of confusion among EZproxy users arises when they start using position sensitive directives in the EZproxy configuration file.

Some rules, like the SSL Cipher directives, must be positioned before other directives (LoginPortSSL in this case).

Others turn certain features on and have a complimentary directive that turns them off (Option DomainCookieOnly / Option Cookie; AutoLoginIP / ExcludeIP / IncludeIP; etc)

Getting to know all of these directives, their relationships, when to use, and in some cases when to not use them can be a steep learning curve for new EZproxy users.

The solution to several of these issues would be to adopt a new structured configuration file format, one similar to Apache HTTPD.

Let's take a look at what a before and after might look like for a few stanzas:

Option DomainCookieOnly
Title -hide EBSCO LinkSource
URL http://linksource.ebsco.com
HJ linksource.ebsco.com
Option Cookie

Here's what this might look like if the Apache HTTPD style were adopted:

<Database "EBSCO LinkSource">
    HideTitle
    URL http://linksource.ebsco.com
    HJ linksource.ebsco.com
    Option DomainCookieOnly
</Database>

It's not a dramatic change, but now it is clear what the DomainCookieOnly is limited in scope to the EBSCO LinkSource database.  It eliminates the possibility that the "Option Cookie" line is forgotten and impacts a different database stanza.

Here's another idea:

URL http://alexanderstreet.com/
Domain alexanderstreet.com
Host ahiv.alexanderstreet.com
...
Host womv.alexanderstreet.com

Almost a screen full of Host directives complete that stanza!

Why not enable making it simpler, like so:

<Database "Alexander Street Press">
    Domain alexanderstreetpress.com
    Host *.alexanderstreetpress.com
</Database>

Those seem pretty straightforward, and easy to follow.  Now let's look at some core configuration.

Before:

Interface Any
LoginPort 80
Option ForceHTTPSLogin

Option DisableSSL56bit

Option DisableSSLv2

LoginPortSSL 443

IncludeFile databases/vendorA

IncludeFile databases/vendorB

IncludeFile databases/vendorC

As mentioned above, there is an ordering that needs to be observed for those directives to work, and do what they are intended.  If you have a group of Option directives in you configuration file that happens to appear after the LoginPort, and blindly add the DisableSSL settings, you will not actually disable the weak SSL cipher support.

What if that were configured more like Apache VirtualHosts:

<VirtualHost [IP Address #1]:80>

    IncludeFile databases/vendorA

    <Authentication ReferringURL>

        URL http://lib.example.edu/

    </Authentication>

</VirtualHost >

<VirtualHost [IP Address #2]:80>

    IncludeFile databases/vendorB

    <Authentication Ticket>

        TimeValid 10

        MD5 somekey

        Expired Deny expired.html

    </Authentication> 

</VirtualHost >

<VirtualHost [IP Address #1]:443>

    ForceHTTPSLogin

    DisableSSL56bit

    DisableSSLv2

    IncludeFile databases/vendorC

    <Authentication File>

        URL file:///path/to/users.txt

    </Authentication>

</VirtualHost >

Here we have 3 proxy instances on 2 different IP addresses, one setup for SSL.  The first does referring URL authentication to Vendor A, the second does ticket-based authentication for Vendor B, and the third uses SSL for Vendor C for a subset of users.

An approach like this would make the multi-site proxy approach easier to setup.  The nightmare scenario where you have multiple campus locations, each teaching different programs, each with different capabilities when it comes to user authentication, each with different sophistication levels of the web site that patrons are going to be using.

Setting up something as complex as that example in EZproxy today with its flat configuration would require the use of Groups, multiple Interface directives, very careful ordering of directives, and extensive testing.  I could probably generate a working equivalent, but it would take a bit of time to work it all out and make sure that it was functioning as designed.

With a structured configuration format like the strawman proposal above, you can see how it is obvious which rules are applying to which database, without having to scour the file for context, and with the right hierarchy of directives, the amount of time spent designing and testing such a setup can be reduced significantly.