So, the reason we wanted to proxy scholar.google.com is that google provides link resolver links if the requesting IP is our domain. Otherwise, each remote user will have to configure their own browser.  GoDaddy wouldn't let me add scholar.google.com.librarycatalog.vts.edu to my certificate. So unless there's a script we can use to let users click on a link and automatically register their scholar link resolvers, we have to explain in further detail to them.  That's the only proxying of google.com that we wanted to do.

Cindy Harper

-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Andrew Anderson
Sent: Saturday, January 16, 2016 3:25 AM
To: [log in to unmask]
Subject: Re: [CODE4LIB] [patronprivacy] Let's Encrypt and EZProxy

On Jan 15, 2016, at 13:20, Salazar, Christina <[log in to unmask]> wrote:

> Something that I also see implied here is why aren't vendors doing a better job collaborating with the developers of EZProxy, instead of only putting the pressure on Let's Encrypt to support wildcard certs (although I kind of think that's the better way to go).


Because it's easier than actually taking the time to fully understand the platforms and how all the pieces fit together.  

I've lost track of how many discussions I have had with various vendors recently over:

* Why they need to encode URLs before trying to pass them to another service like EZproxy's login handler
* Why they really do need to pay attention to what RFC 2616 Section 3.2.2 and RFC 2396 Section 2.2 have to say regarding the use of the reserved character in URLs
* Why it's a bad idea to add "DJ google.com" in the EZproxy stanza
* Why it's a bad idea to add "DJ <CDN SERVICE>" in the EZproxy stanza
* Why it's a bad idea to add "DJ <unrelated public server>" in the EZproxy stanza

Instead of trying to understand how proxied access works, someone just keeps slapping "DJ <random domain>" or "HJ <random host>" into the service stanza until the service starts working, and then never revisits the final product to see if those additions were really necessary.  Do this for a few platform iterations, and the resulting stanza can become insane.

The conversations typically go something like this:

Me: "Why are you trying to proxy google.com services?" 
Vendor: "Because we're loading the jQuery JavaScript library from their CDN."
Me: "And how are you handling registering all your customer's IP addresses with Google?" 
... <silence> ... 
Vendor: "We don't".
Me: "Then why do you think you need that in your proxy stanza?". 
... <silence> ...
Vendor: "We . . . don't?"
Me: "Exactly. And how are you reaping the performance benefits of a CDN service if you're funneling all of the unauthenticated web traffic through a proxy server instead of allowing the CDN to do what it does best and keeping the proxy server out of the middle of that transaction?"
Vendor: "We . . . aren't?"
Me: "That's right, by adding 'DJ <CDN SERVICE>' to your stanza, you have successfully negated the performance benefits of using a CDN service."

-- 
Andrew Anderson, President & CEO, Library and Information Resources Network, Inc.
http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | http://www.facebook.com/LIRNnotes