JSTOR translator error

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
  • [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.)
  • (I've asked a technical follow-up over on zotero-dev: https://groups.google.com/u/1/g/zotero-dev/c/ye9o18HECEM )
  • Whoops, new one is D1185947954

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

    Thank you both!
  • 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.
  • 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.
  • 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)
  • 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?
  • 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.
  • 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!
  • 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.
Sign In or Register to comment.