Login required for access to public group via API

jphekman

Group: 83856 (public to read, requires membership to write). My understanding is that the public should be able to access this group's data via the API without an API key -- am I right?

When I try to access the group's library like so:

https://api.zotero.org/groups/83856/items/top?format=atom&content=bib

then I get a login request (through my browser, not through a login screen on a web page). When I hit "cancel" I get an "invalid login" message (or something similar -- that may not be the correct error message). If I then reload the page, the Atom feed displays correctly. I can then continue to successfully reload the page, though if I try to load it on another machine I get that initial authentication challenge again.

If I try to subscribe to the Atom feed in Google Reader, Reader says there are no entries. If I try to load the feed in to a WordPress installation through its mechanism for loading in an outside feed, WordPress complains that it can't access the feed. I believe that both of these applications received authentication challenges and did not know how to respond.

Thanks for any help you can give!

dstillman

I can't tell you why you're getting authentication prompts, but the Zotero servers definitely aren't returning auth challenges for that URL. (You can try it yourself in cURL, if you know what that means.)

dstillman

From our logs, it looks like you actually connected from WordPress to www.zotero.org, not api.zotero.org.

Google Feedfetcher appears to have retrieved the feed successfully and is now getting 304 Not Modified responses. In case something went wrong the first time, you might try deleting the feed and recreating it to try to trigger a new complete pull.

dstillman

And for the prompt for your browser-based requests, I think that's just an artifact of your browser caching authentication credentials after performing a Zotero sync. We can probably fix that, but the API wouldn't return that for regular requests from other clients. I also doubt it would do that after restarting Firefox before performing a Zotero sync.

jphekman

Thanks so much for taking a look in the logs to see what's happening.

You're right, it works perfectly in curl. Using wget, I get this error:

ERROR: cannot verify api.zotero.org's certificate, issued by `/C=US/O=Equifax/OU=Equifax Secure Certificate Authority':
Unable to locally verify the issuer's authority.
To connect to api.zotero.org insecurely, use `--no-check-certificate'.

(When I use wget --no-check-certificate, it works fine.) I added a new item to the feed and checked Google Reader, which also now works (that's fantastic). However, the WordPress blog that I am trying to load the feed into (using a widget) is still saying that it cannot access the feed. I wonder if WordPress is having certificate problems similar to wget? (I really wish WordPress gave me a better error message!)

Would you mind checking to see if you are getting requests from wordpress.com for this feed? The exact URL that I gave WordPress.com is

https://api.zotero.org/groups/83856/items/top?content=bib

and the blog that I am using to test loading the feed into WP is

https://ufsmread.wordpress.com/

I am hopeful that your logs could tell me whether WordPress.com is in fact sending the correct request, and maybe even if it is hung up on your SSL cert for some reason.

Thanks again for your help, I appreciate it.

dstillman

wget works fine for me on OS X, so that's just an issue of the certs your copy has available.

I don't see anything obviously from WordPress, though if you can add a unique identifier (e.g., "&hdfshj=1") to the request URL (and not request that from anywhere else) I can check for that. But perhaps the widget just doesn't support HTTPS URLs?

I actually misread the request I saw in the logs yesterday, which I think was just you clicking through to the invalid www.zotero.org API URL from the blog.

jphekman

Thanks, Dan! I added &wordpressjph=1 to the URL.

dstillman

Yeah, that's not reaching us at all. (Well, not making it into any logs. An SSL negotiation failure wouldn't show in the logs. Our cert is perfectly valid, though.)

jphekman

OK. I agree that the fault is decidedly not with you. (Stupid WordPress.) Thanks so much for the debugging help. Very much appreciated.