@stuart.yeates wrote:
This post is a summary of an issue related to PDF.js and the EZproxy software by OCLC used to by libraries to proxy resources. It's somewhat more verbose than it might be to include all likely search terms for this issue.
In this example I'll use the OJS server http://mapress.com/ but the issue affects many for-pay installs of OJS when used through EZproxy. I'll be using my institutional EZproxy install. For the example resource:
http://mapress.com/j/zt/article/view/zootaxa.4150.4.1/7282
We proxy it as
http://mapress.com.helicon.vuw.ac.nz/j/zt/article/view/zootaxa.4150.4.1/7282
but the iframe is being rewritten as:
<iframe src="http://mapress.com.helicon.vuw.ac.nz/j/plugins/generic/pdfJsViewer/pdf.js/web/viewer.html?file=http%3A%2F%2Fmapress.com%2Fj%2Fzt%2Farticle%2FviewFile%2Fzootaxa.4150.4.1%2F7282" width="100%" height="100%" style="min-height: 500px;" allowfullscreen webkitallowfullscreen></iframe>
Clearly the second instance of host name in the URL isn't being rewritten. When the javascript tries to access that non-rewritten URL it's flagged as a cross-site security issue and fails hard with the message "PDF.js v1.0.907 (build: e9072ac) Message: Unexpected server response (0) while retrieving PDF "http://mapress.com/j/zt/article/viewFile/zootaxa.4150.4.1/7282"."
The short-term fix for EZproxy admins is for the EZproxy stanza for this resource to include the two lines to rewrite the javascript:
Find file=http%3A%2F%2Fmapress.com
Replace file=http%3A%2F%2F^Pmapress.com^The longer-term solution would be to switch from using absolute to using relative URLs when passing the info to PDF.js. Is this likely to be possible?
Posts: 2
Participants: 2