JSTOR translator error

yehudadavis

I am attempting to save from https://www.jstor.org/stable/2674693 using my university proxy.
When I hover on the button, it says "Save to Zotero (JSTOR)."
When I click it, it says, "An error occurred saving with JSTOR. Attempting to save using Embedded Metadata instead."

Debug ID: D1941873628

dstillman

[JavaScript Error: "HTTP GET https://[…].edu:3081/doiRA/10.2307%2F[…] failed with status code 404"]

Can you provide a Debug ID for the actual save? The one you provided doesn't actually show you saving. Make sure you reload the page first, since otherwise clicking the save button just reopens the popup without saving again.

If you go to the Zotero Connector preferences and look at your proxy entry containing ":3081", do you see "doi.org" listed below as a host? If so, delete "doi.org" from there and try again.

(Your university uses an older port-based EZproxy configuration (e.g., "proxy.school.edu:3081"), whereas most institutions these days use the domain-based approach (e.g., "jstor-org.proxy.school.edu"). Zotero works much better with the latter. Not sure exactly what happened here, but that might be contributing to the problem.)

adamsmith

(I've asked a technical follow-up over on zotero-dev: https://groups.google.com/u/1/g/zotero-dev/c/ye9o18HECEM )

yehudadavis

Whoops, new one is D1185947954

"doi.org" is not listed as a host.

Thank you both!

yehudadavis

Looking through the logs, it looks like @dstillman is correct:

(3)(+0000001): Translate: Validating DOI 10.2307/2674693

(3)(+0000000): Translate: resolving URL https://doi.org/doiRA/10.2307/2674693

(3)(+0000001): Translate: resolved to https://doi.org/doiRA/10.2307/2674693

(3)(+0000000): Translate: proxified to https://[...].edu:3081/doiRA/10.2307/2674693

I double and triple-checked, but doi.org is not in any of my proxies. Not sure why it's getting proxified, but that is obviously why it is failing.

yehudadavis

https://github.com/zotero/zotero-connectors/issues/219#issuecomment-363026047

"Every call to ZU.doGet(url) calls translate.resolveURL(), which, if the translation is happening from behind a proxy and unless disabled via the function argument, proxifies the URL"

This looks like what's happening here.

adamsmith

I think that's right, yes. FWIW, proxying doi.org/doiRA/10.2307/2674693 should absolutely work, so I do think that's a problem with your proxy. I also don't know if we want to blacklist doi.org (although we could blacklist doi.org/doiRA without any issues)

yehudadavis

Good point. I ran doi.org/doiRA/10.2307/2674693 through the proxy and it used port 2065. I created the rule to run doi.org through the proxy and can verify that when I go to that doi.org link, it proxies through https://[...].edu:2065/doiRA/10.2307/2674693 and properly returns the JSON.

However, when I attempt to save from JSTOR, it doesn't follow the new rule I added, and is still trying to access through the JSTOR proxy port of 3081.

Am I doing something wrong? Or is the code reusing the proxy from the existing page, even when fetching a url with a different hostname?

adamsmith

No, you're doing everything right. Port-based proxies are just hitting Zotero's limits in dealing with proxy redirection properly. Thankfully, they're on their way out, but I think we'll be able to fix this for you in some way. Let's wait for dstillman to chime in with his preferred solution.

yehudadavis

BTW, for new sites, I use "https://[...].edu/login?url=" to get my university to forward to the correct port-based proxy. Then I accept the automatic proxy rule from Zotero. Would it make more sense to make one rule using the above url? Would that solve this problem?

Thanks!

dstillman

Ah, yeah, I forgot that we're proxying all HTTP requests, even for different domains, when translation starts proxied. I'm not sure when that's actually necessary, but I assume we have a reason for it. And we haven't yet gotten around to exposing a noProxy option for requests (though we have a similar proxy flag for attachment downloads).

I also don't know if we want to blacklist doi.org (although we could blacklist doi.org/doiRA without any issues

We're currently set up to block hosts more easily than URLs, though we could change that. But I don't think blocking doi.org would be a problem. If you actually load a doi.org URL, you don't need the initial request proxied. You do for the redirect, but Zotero should handle the proxying on that request separately. And within a translator, I assume a redirect from a content-negotiation request would always be public (e.g., to data.crossref.org). So unless @adomasven can think of a reason not to do this, it seems like we could just add doi.org to the blocklist, as we did for eutils.ncbi.nlm.nih.gov.

yehudadavis

I am still having this issue. Am I able to manually add doi.org to the blocklist instead of waiting for a more permanent fix?
Thanks!

yehudadavis

Oh, it looks like I can do it in the proxy.js file

yehudadavis

...and that makes Chrome think the extension is corrupted.
Any suggestions?

Thanks!

dstillman

doi.org is now blocked from being proxied in the latest Zotero Connector beta for Firefox.

Let us know if this resolves the issue for you.

yehudadavis

@dstillman yes, I installed Firefox and added my JSTOR proxy, and it imported it without a hitch.
Thank you!

Do you know when the updated version will show up in the Chrome store?

mh

"An error occurred saving with JSTOR. Attempting to save using Embedded Metadata instead." I'm getting this message repeatedly. A (partial?) save happens anyway. What is the fix for this problem?

dstillman

URL?