Well bad news, the URL and headers received from my hosted app from a
Tweepy GET request were identical in prod vs. dev. We might need to go back
to attacking from the Twitter side to see if they can explain why they're
rejecting our API requests.
I realized when requesting from a dummy URL I didn't need to worry about
changing nonce and timestamp; I just hard-coded them (to realistic values)
to see if the oauth signatures were the same. And they were. So I have
failed to identify what these punctuation characters have to do with the
authentication error.
Caveat: the signatures are the same, but the 'Authorization' request header
is slightly different; its elements are ordered differently in prod vs dev
for whatever reason. But I'm not really concerned because the ordering is
the same regardless of whether I use the punctuation; i.e. dev and prod
Authorization headers differ in the same way even for requests that would
return a successful response from the Twitter API.
To see what I'm talking about, here is the Authorization request header in
production:
'OAuth realm="", oauth_nonce="12345678", oauth_timestamp="1430361562",
oauth_consumer_key="xxxxxxxx", oauth_signature_method="HMAC-SHA1",
oauth_version="1.0", oauth_token="yyyyyyyyyyyyy",
oauth_signature="AiqwN51QaZnwsBkikcVh9rENc84%3D"'
And here it is in dev:
'OAuth realm="", oauth_token="yyyyyyyyyyyyy", oauth_nonce="12345678",
oauth_timestamp="1430361562",
oauth_signature="AiqwN51QaZnwsBkikcVh9rENc84%3D", oauth_version="1.0",
oauth_signature_method="HMAC-SHA1", oauth_consumer_key="xxxxxxxx"'
These are for the query "dogs & cat)s" which I confirmed returns the
authentication error from prod (but not dev). In each case the URL
requested of my hosted app is:
/1.1/users/search.json?q=dogs%20%26%20cat)s
Note that the ) is not encoded. However, that remains the case when calling
from dev, so I don't see why this could be the cause of the problem.
On Wednesday, April 29, 2015 at 1:29:34 PM UTC-5, Ryan Barrett wrote:
>
> thanks for the comprehensive debugging, Dave and David! it definitely
> sounds like new header munging on app engine's part may be the problem.
> Dave, your idea of sending the API calls to a different endpoint and
> examining the headers sounds like a great lead. i'm looking forward to the
> results!
> as another data point, there may be more to it than just punctuation
> characters. i see the error with pretty much any tweet content and
> username. i reproduced it just now by attempting to tweet "foo" (just those
> three characters) as @schnarfed. sigh.
>
> On Wednesday, April 29, 2015 at 9:58:38 AM UTC-7, Dave Loomer wrote:
>>
>> (what I was getting it with the previous post is: if any of you need this
>> for your day jobs, you are welcome to try the same yourselves in the
>> meantime ;) )
>>
>> On Wednesday, April 29, 2015 at 11:56:52 AM UTC-5, Dave Loomer wrote:
>>>
>>> All: I won't have time to do this in the next several hours (my app
>>> engine app is not my day job), but I think tonight I'll try changing the
>>> api.twitter.com endpoint to point to a URL I own, and then examine the
>>> URLs / query strings and headers received from my prod vs. dev code to see
>>> if the encoding is any different.
>>>
>>> I figure that could help point to whether it's a urlfetch issue. Only
>>> other thing I can think of, if it's not urlfetch, is that the oauth
>>> signatures are being generated differently in prod vs. dev, due to a
>>> difference in some built-in python library on the prod server, and that
>>> will be much more difficult to debug since the timestamp and nonce prevent
>>> you from comparing dev vs prod requests character-by-character.
>>>
>>>
>>> On Wednesday, April 29, 2015 at 9:36:17 AM UTC-5, Ryan Barrett wrote:
>>>>
>>>> hi all! a number of us have started seeing twitter API errors in prod
>>>> GAE in the last week or so. write calls and some search calls are
>>>> returning
>>>> HTTP 401 {"errors":[{"code":32,"message":"Could not authenticate
>>>> you."}]} for all users with no code changes on our end. the
>>>> particularly odd part is that the same calls with the same code, twitter
>>>> app key/secret, and even *the exact same user access token key/secret*
>>>> work fine in dev_appserver.
>>>>
>>>> we're on python and mostly using tweepy. our current theory is that
>>>> twitter has blacklisted or graylisted app engine's external facing IPs.
>>>> can
>>>> you think of any other ideas?
>>>>
>>>> more details in this twitter dev forum post.
>>>> <https://twittercommunity.com/t/post-to-statuses-update-json-started-hitting-error-32-could-not-authenticate-you-with-no-code-changes/36495>
>>>>
>>>> thanks in advance!
>>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-appengine.
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-appengine/7a1e862a-cd44-4560-9e37-c34d2326a31d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
