Not only that, but it's also expressly designed for the purpose of reverse
proxying subscription databases in a library environment. There are tons
of things vendors do that would be incredibly frustrating to get working
properly in Squid, nginx, or Apache that have already been solved by
EZProxy. Which is self-fulfilling: vendors then cater to what EZProxy does
(rather than improving access to their resources).
Art Rhyno used to say that the major thing that was inhibiting the
widespread adoption of Shibboleth was how simple and cheap EZProxy was. I
think there is a lot of truth to that.
On Fri, Jan 31, 2014 at 1:23 PM, Kyle Banerjee <[log in to unmask]>wrote:
> > EZproxy is a self-installing statically compiled single binary download,
> > with a built-in administrative interface that makes most common
> > administrative tasks point-and-click, that works on Linux and Windows
> > systems, and requires very little in the way of resources to run. It
> > has a library of a few hundred vendor stanzas that can be copied and
> > and work the majority of the time.
> > To successfully replace EZproxy in this setting, it would need to be
> > packaged in such a way that it is equally easy to install and maintain,
> > the library of vendor stanzas would need to be developed as apache conf.d
> > files.
> This. The real gain with EZProxy is that configuring it is crazy easy. You
> just drop it in and run it -- it's feasible for someone with no experience
> in proxying or systems administration to get it operational in a few
> minutes. That is why I think virtualizing a system that makes accessing the
> more powerful features of EZProxy easy is a good alternative.