Mixed content security warnings in search results and record details

[Dan Scott]

* Evergreen 2.0.6

When accessing search results or record details via HTTPS in the default skin, browsers raise a mixed content warning due to the presence of JavaScript resources loaded via hardcoded HTTP URLs. While users can easily disable these warnings, that's not a security practice that we want to encourage or be responsible for.

Accordingly, the branch at http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commit;h=b65195ba579485681a8a304495abd47836257b9a contains a fix that sets the protocol for the requests to Google to match the page protocol.

Please review and merge if acceptable.

[Dan Scott (denials)]

Turns out that this is impossible to fix unless we proxy the requests ourselves - at least, not without switching to the new v1 API for Google Books, which then adds the complication of needing an API key and being limited to 1,000 requests / day (by default - can be extended by request, but is it worth adding this to the complications in our current JavaScript configuration? Methinks no.)

So the right way to resolve this is probably to treat Google Books as just another added content provider and to proxy the requests via the Evergreen server (while enabling the configuration bits for API key etc to be configured in opensrf.xml).

I will kill my branch accordingly.

[Jason Stephenson (jstephenson)]

Is someone working on this? If so, please change status to In Progress?

[Dan Wells (dbw2)]

Here are a few branches which attempt to deal with this issue (and switch to the new Books search API, a needed step).

For master:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dbwells/lp787295_google_book_api_and_ssl_change

For 2.1 and 2.0:
http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/collab/dbwells/lp787295_google_book_api_and_ssl_change_2_1

To quote the commit message:

Switch to new Google Books API; make SSL friendly

As implied in the title, this commit does two things. First, it
switches to the new Google Books API (which is both imminent and
also necessary to make SSL calls work). Though the information is
scant, from what I have read and experienced, we do not need an
API key to do searches and previews. I have also not hit any kind
of unauthenticated limit in several days of heavy testing, so I
would figure we are safe (at this point) for normal end-user OPAC
browsing.

Second, all Google Book requests are now done over https. This
eliminates the majority of mixed content warnings when browsing
securely, though you still get a warning when you actual do preview
a book.

In addition to possibly implementing protocol detection (rather
than doing https all the time as a "lowest" common denominator),
there are a few minor points where we might consider future changes.
Those points are commented within the code.

Thank you,
Dan

[Dan Scott (denials)]

The API was pretty restrictive back in May when it originally launched; I would get locked out if I ran five or so anonymous queries against the Google Books API within the span of a few seconds, so it sounds like they've relaxed that since then. Good news!

Merged into our production 2.0 system and it works nicely - thanks Dan! Committed to rel_2_0 through master.

[George Duimovich (george-duimovich)]

We're running 2.1.1 and this bug appears to affect us in IE8 (tested in default skin).

Can your patch be backported for use on 2.1.1 system or is it only for 2.2.0?

[Dan Wells (dbw2)]

Hello George,

This fix has already been backported and will appear in Evergreen 2.1.2.

Dan