401 on /statuses/retweet, but not /statuses/update

martok_sh · 2013-05-19T19:16:23.000Z

Hello,
I’m seeing something odd here: POST requests to the /statuses/update.json endpoint work perfectly fine, same goes for everything DM-related. However, POST to /statuses/retweet/:id.json constantly return 401 “32: Could not authenticate you”.
From what I see in the documentation, both require the same user-context authentication which I have - for legacy reasons, the app is still on OAuth 1.0, so it only has user context anyway. Additionally, this same issue also existed using the 1.0 API with the same application in the past week, but not before.

Is there a new undocumented difference in requirements? The code firing the two is precisely the same, and header-wise everything looks sane to me.

EDIT:
This issue has actually a wider scope than I thought. I receive a 401 for every POST to an endpoint acting on a specific status, ie. everything written as …/:id.json in the documentation. Examples are status/retweet/:id and status/destroy/:id. Things like favorite/create transfer the ID in their request parameters and are perfectly fine.

So, to rephrase the question: why do requests transmitting their resource id require a different sort of authentication, and how does it differ…

episod · 2013-05-20T15:13:18.000Z

Can you provide some examples of your OAuth in these interpolated parameter cases? Maybe there’s something going haywire in how you’re evaluating the parameters in the signature base string.

martok_sh · 2013-05-20T18:03:39.000Z

Actually, this seems to be more a documentation issue than anything else.
On your side, the OAuth verification requires the id to be re-stated as a parameter when signing, i.e. the signature has to be computed over
…/statuses/retweet/1234.json&id%3D1234%26oauth_consumer_key%3D…
However, the id parameter according to documentation is only given as the REST resource object, not as a parameter (note that the example states “POST data: none”), so of course the simple approach of “sign method&url&everything we post+oauth” will always produce wrong signatures.

It seems to me that there has been a patch about 5 days ago that introduced this, not including the id as a parameter for the signature worked fine before. Also, both APIv1 and APIv1.1 are affected equally…

“Fixed” for now by POSTing the id as a parameter as well as in the URL which makes my signing code behave, but I’m not sure if the whole thing is even intentional? Both alternatives (sign a parameter twice and/or transmit a parameter twice) feel somewhat odd.