Note that the special sauce required to make that work is "Option HttpsHyphens" which collapses scholar.google.com.ezproxy.example.org to scholar-google-com.ezproxy.example.org.
cheers stuart -- ...let us be heard from red core to black sky On Wed, Mar 4, 2015 at 7:19 AM, Andrew Anderson <[email protected]> wrote: > https://pluto.potsdam.edu/ezproxywiki/index.php/SSL#Wildcard_certificate > > (You can safely ignore the SSL warning, pluto uses self-signed certificates) > > -- > Andrew Anderson, Director of Development, Library and Information Resources > Network, Inc. > http://www.lirn.net/ | http://www.twitter.com/LIRNnotes | > http://www.facebook.com/LIRNnotes > > On Mar 3, 2015, at 11:46, Karl Holten <[email protected]> wrote: > >> If you're using proxy by hostname, it's my understanding that you need to >> purchase a SSL certificate for each secure domain, otherwise you get >> security errors. Depending on how many domains you have, the cost of this >> can add up. Maintaining it is a headache too because it seems like vendors >> often don't bother to notify you they're making a switch. >> >> If there's some way to avoid doing this, I would love to know! >> >> Karl Holten >> Systems Integration Specialist >> SWITCH Inc >> 414-382-6711 >> >> -----Original Message----- >> From: Code for Libraries [mailto:[email protected]] On Behalf Of >> Stuart A. Yeates >> Sent: Monday, March 2, 2015 5:27 PM >> To: [email protected] >> Subject: [CODE4LIB] making EZproxy http/https transparent >> >> In the last couple of months we've had to update a number of EZproxy stanzas >> as either tools migrate to HTTPS-only or people try to access HTTP/HTTPS >> parallel resources using browsers that automatically detect HTTP/HTTPS >> parallel resources and switch users to the HTTPS version (think current >> Chrome, anything with the HTTPSeverywhere plugin). >> >> We'd like to avoid updating our config.txt piecemeal on the basis of >> user-gernated error-reports >> >> We're thinking of going through our EZproxy config.txt and adding an H >> https:// for every H or URL entry. (Domain and DomainJavascript already work >> for both HTTP and HTTPS). >> >> Has anyone tried anything like this? Are there pitfalls? >> >> cheers >> stuart >> -- >> ...let us be heard from red core to black sky
