Handling 401 responses

[Mihai Parparita]

Brad Hawkes (another Reader engineer that covered for me while I was on vacation) might have mentioned this already, but I wanted to make sure you were all aware of how to handle 401 responses correctly. 401s will happen for /reader/api/0/... requests when the passed in SID authentication cookie is not valid. The right way to proceed is not to retry (a limited number of retries is OK for 500-level responses) but to display an error message for the user and to ask them to log in again.

We recently (a few weeks ago) started to enforce two-week expiration for sessions on API requests (the regular Reader UI was already doing this, i.e. if you hit /reader/view with an old cookie, you got a redirect to the login page), so you might be seeing 401 more often than usual. We also last night invalidated all currently logged in sessions (due to a Google-wide configuration change), in case you see more reports than usual of your apps not being able to log in.

Mihai

[Mariano Kamp]

Hi Mihai,

I was under the impression that some calls return a 401, but others, like the atom feed for a reading list, will return a 302 and redirect to the login page. That is not the case anymore?

Currently I don't store the google password on the device and as it was never expired this was convenient and "secure" at the same time ;-) Now, with the recent change it might become inconvenient not to store the password. 

I'd like to take this as the trigger to think about adopting the Android 2.0 accounts framework. It would be much safer anyway, if I don't get my hands on the password anymore. Consider what will happen if a NewsRob users gets his identity stolen? I am in a bad situation then. The new accounts framework is a Google provided way to deal with all kinds of authentications, one of them Google authentications, in a safe way.

I am able to use it to authenticate for Google Apps, but unfortunately the authToken I get looks and feels like a SID I get from ClientLogin, but doesn't work with Google Reader. I always get a 30x.

There is no documentation on how to use this framework with Google and no working sample code. I am wondering if you have an idea where to go from here? Anybody I can annoy with my questions and failing sample code?

Btw. word on the street is that the auth-domain should be "ah", which works up to the point to get an auth token, whereby other domains just throw an error. Any other string I could try?

[Mihai Parparita]

(I know nothing about the Android accounts framework)

The difference in behavior between /api and /atom is that API
endpoints are supposed to return a 401 (which is more easily detected
in code), while URLs that users are likely to request directly should
redirect to the login page (hence the 302). /atom is considered to be
a user-visible page, since at least our own API use has switched to
/api/0/stream/contents for getting at stream data.

Mihai

[Mariano Kamp]

Also, it seems that CAPTCHAs now need to be handled. Before the REQUIRE-CAPTCHA status was cleared, when the user-relogged in from the web app.

Any idea how to force a REQUIRE-CAPTCHA? Just passing the wrong password a couple of times doesn't seem to do the trick.

[Mihai Parparita]

(adding the group back)

Can include the full request that you're sending? When I request my reading list with no authentication, I get a 401:

$ curl -v http://www.google.com/reader/api/0/stream/contents/user/14548369432350969777/state/com.google/reading-list
...
< HTTP/1.1 401 Unauthorized

Mihai

On Wed, Jun 2, 2010 at 9:36 PM, Dylan <dy...@theginsburgs.org> wrote:

I'm testing out my error handling of 401's but when I don't put any
authentication credentials on api/0/stream/contents queries I'm
getting back a 400. Is this expected? Should I treat this as an
indication the user needs to re-authenticate?

Thanks.