3

For almost all API calls, I pass both my key and my access_token. This doesn't exactly make sense for the "de-authenticate" endpoint, as the access token is already in the URL. Passing one anyway yields a rather unhelpful 500 error, although the user is successfully deauthenticated.

I've put together a quick page to show the error:

http://withoutthesarcasm.com/stackapps/bug/

The "error" link will de-authenticate with the access_token passed as a GET parameter as well as in the URL, and the "OK" link will de-authenticate without passing the access_token as a GET parameter.

Probably a low severity bug, but I thought I'd report it anyhow.

Improve this question

1 Answer 1

Reset to default
3

A fix for this has been deployed.

The error was in updating the throttle after the access token was invalidated, so now the token lives on from the perspective of the request making it until it completes. It is, however, destroyed immediately from the perspective of any other requests at the time.

Improve this answer
3
  • 1
    Makes sense. Thanks for the fix. Should I pass the access_token as part of the GET parameters, so as to get the request properly tracked from a throttle perspective? Or can you guys do this from the access_token in the URL? I don't think it matters that much (throttle-wise, it's a tiny amount of the total requests) but I thought I'd ask anyhow.
    – agent86
    Commented Jan 25, 2012 at 22:06
  • @agent86 - pass it as a parameter, for simplicity and consistency throttling doesn't look for anything other than ?access_token=....
    – Kevin Montrose
    Commented Jan 25, 2012 at 22:22
  • Sounds good, will do.
    – agent86
    Commented Jan 25, 2012 at 22:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .