Saturday, November 30, 2013

And another fail scenario for EZproxy: GeoScienceWorld and the Google Maps API

This issue resolved by GSW December 8

To borrow a line from Jonathan Rochkind's Bibliographic Wilderness 'EZProxy is terrible, it's just the best we've got.' 

I don't think it's terrible but it's always been a pain that TOC services don't work off campus and that RSS feeds occasionally don't work at all, but this week I got a something new.

GeoScienceWorld's search interface includes a world map that uses the Google Maps API. -  and if we access the search page via ezproxy (and we default all users through EZProxy - even on campus) Google Maps refuses to serve data because the API Key is not registered for use in our domain (i.e. it works if you strip out the EZProxy suffix 'elibrary.jcu.edu.au')
This is the message
Google has disabled use of the Maps API for this application. This site is not authorized to use the Google Maps client ID provided. If you are the owner of this application, you can learn more about registering URLs here: https://developers.google.com/maps/documentation/business/guide#URLs
This happens as soon as you try to access GSW's search because the map is built into the search form - even if you don't want to use it.  That message appears in a dialog box - it scares off most users, who don't realise clicking 'OK' will get you to vanilla searching (sans Map) but that gives the impression search might be broken because the map disappears leaving a worryingly blank blue square.

If we remove the proxying from the link in our A-Z of database pages it will work for on campus users but off campus users won't get access to the website at all because of the IP restriction.

I haven't worked with Google Maps API - but my reading of their authorisation doco suggests there isn't a simple workaround. The prevention of other sites using your app is intentional - in a library context it's a barrier. I'm going to guess that GSW isn't interested in registering every subscriber's EZProxy domain even if it's possible.

Will be getting our people to talk to their people to see what can be done, and if anyone else has mentioned it.

People have suggested that in the future the EZProxy fail situations might be resolved by Shibboleth, or some other middle tier authentication broker. Right now I'm suggesting that power users use the VPN and strip the EZProxy suffix. Being a specialist resource most users should be easy to define (Earth Sciences), and therefore easy to inform of the problem and workarounds.

Will comment if GSW get back to  us.

4 comments:

Doug Eriksen said...

Alan, I think the NeverProxy declaration is going to help you solve this. I haven't tested your exact scenario (components of an otherwise proxied page loading unproved via a NeverProxy declaration), but I have used it to deal with situations where I can't control how people link to a resource that won't work if they create a proxied link, and my reading of the docs (the PDF reference manual, there isn't much about it on the support website) suggest it could solve your problem.

Alan @JCU Library said...

Hi Doug

Thanks for the tip - I will pass it on to my EZproxy admin. Much appreciated - Alan.

Alan @JCU Library said...

Sadly Neil tells me he's tried this unsuccesfully. Sniff.

Alan @JCU Library said...

GSW resolved this over the weekend of December 2013