401 errors - 1.1 search

ghentsch · 2012-10-15T15:15:37.000Z

I’ve been struggling trying to convert our software to 1.1. I have rate limits working fine but searches continue to give me a

“The remote server returned an error: (401) Unauthorized.”

I’m not sure why the rate limit works and the search doesn’t. Here’s the rate limit string I use:

GET&https%3A%2F%2Fapi.twitter.com%2F1.1%2Fapplication%2Frate_limit_status.json&oauth_consumer_key%3DZO1nqqmS77mfNP7v17zraA%26oauth_nonce%3DNjM0ODU4OTAwNDg5MzI1MDAw%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1350307649%26oauth_token%3D19739039-IoUouCpvUgRyMN2wz5b0NtFfuOsgnoVHcaOYnuiPH%26oauth_version%3D1.0

and the failed search is:

GET&https%3A%2F%2Fapi.twitter.com%2F1.1%2Fsearch%2Ftweets.json&q%3Dgreat%2520AND%2520gatsby%26rpp%3D19%26result_type%3Drecent&oauth_consumer_key%3DZO1nqqmS77mfNP7v17zraA%26oauth_nonce%3DNjM0ODU4ODk5NDc3OTE4NzUw%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1350307549%26oauth_token%3D19739039-IoUouCpvUgRyMN2wz5b0NtFfuOsgnoVHcaOYnuiPH%26oauth_version%3D1.0

Can you see anything I’m doing wrong?

episod · 2012-10-15T15:25:44.000Z

It looks like you aren’t sorting parameters in your signature base string – the q, result_type, and rpp parameters should all appear after the oauth_* parameters since q and r > o.

ghentsch · 2012-10-15T18:47:56.000Z

Thanks. That did the trick. I didn’t know about the sorting requirement. I’m still having a problem with geocode searches though:

GET&https%3A%2F%2Fapi.twitter.com%2F1.1%2Fsearch%2Ftweets.json&geocode%3D46.80328260%2C-71.24279600%2C50km&oauth_consumer_key%3DZO1nqqmS77mfNP7v17zraA%26oauth_nonce%3DNjM0ODU5MDg4MTMzNzAwMDAw%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1350326413%26oauth_token%3D19739039-IoUouCpvUgRyMN2wz5b0NtFfuOsgnoVHcaOYnuiPH%26oauth_version%3D1.0%26q%3Dgreat%2520AND%2520gatsby%26result_type%3Drecent%26rpp%3D19

episod · 2012-10-15T20:08:00.000Z

Commas can get tricky. Ideally your querystring will encode the comma as “%2C” and then your signature basestring would escape that to “%26%2C”.

ghentsch · 2012-10-15T21:22:39.000Z

I still can’t get it to work. I tried “%26%2C”, “%25%2C” and “%252C” (like the oAuth tool generates) in the signature basestring for geocodes. I"m still stuck with 401 errors.

ghentsch · 2012-10-15T21:27:01.000Z

For example, the oAuth generates:

GET&https%3A%2F%2Fapi.twitter.com%2F1.1%2Fsearch%2Ftweets.json&geocode%3D46.80328260%252C-71.24279600%252C50km%26oauth_consumer_key%3DZO1nqqmS77mfNP7v17zraA%26oauth_nonce%3D0b68ef51d725220fd8ec0137a7adb73e%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1350329050%26oauth_token%3D19739039-IoUouCpvUgRyMN2wz5b0NtFfuOsgnoVHcaOYnuiPH%26oauth_version%3D1.0%26q%3D%2523freebandnames

for

q=%23freebandnames&geocode=46.80328260,-71.24279600,50km

I wonder if this is a bug in the tool?

PixxApp · 2013-02-25T20:27:00.000Z

I have the same problem too and have never successfully received any results whatsoever from the search endpoint.
All the other API endpoints that I use work flawlessly using the same oauth lib.

Here’s a uri that fails:

https://api.twitter.com/1.1/search/tweets.json?q=pic.twitter.com&count=50

and the authorization string:

OAuth oauth_signature=“hJe6M%2FQLGwXMFNcra1xJGyaP1uI%3D”,oauth_version=“1.0”,oauth_nonce=“9orIibewog03RRw9”,oauth_signature_method=“HMAC-SHA1”,oauth_consumer_key=“X8VGUu6JRdCDUSCmO6Bg”,oauth_token=“16831433-Qr5D1qTqVOSBboX5tXubtnh72RTOKZf8wC0oARMaV”,oauth_timestamp=“1361823984”

I’m pretty sure the basestring is not the issue because I have more complex requests working properly with many more params including POST params so I assume that this is not the problem.

Taking out the realm parameter did not help and neither switching the oauth versions from 1.0 to 1.0a. I’m lost on this one and looking to release my fully 1.1 compliant app in a matter of days.

Please help :S

episod · 2013-02-26T14:25:57.000Z

Is it that you’re getting no results or that you’re getting an error response? If you’re getting no results but a positive response, it means there are no records to display matching your criteria. The URL encoding rules in 1.1 are a little stricter, and it’s possible that the “.” characters in your querystring aren’t be interpreted correctly. (Perhaps the “.” is being encoded when it’s not suposed to be?"

PixxApp · 2013-02-26T16:19:00.000Z

Strangely enough it seems to have to do with the query itself but it does not explain everything just yet.

When I make this call with my app

https://api.twitter.com/1.1/search/tweets.json?q=pic.twitter.com%20OR%20instagr.am&count=50

it does not work but when I remove the %20OR%20instagr.am resulting in

https://api.twitter.com/1.1/search/tweets.json?q=pic.twitter.com&count=50

it does work. But amazingly on apigee.com both calls work flawlessly. Do they have some privileged status or what?

I’m puzzled

episod · 2013-02-27T15:04:38.000Z

No, it’s just likely that something either in the HTTP or OAuth layer of whatever library you’re using is munging your querystring in some way. The Search API returns an extra bit of metadata that more describes how it interprets the request you’ve sent – maybe the hint as to what’s going wrong is in there.

PixxApp · 2013-02-27T15:49:17.000Z

Problem solved:

Not only should the entire url be url-encoded but the ‘q’ parameter itself must be url-encoded as well so that in the resulting url the ‘q’ parameter is doubly url-encoded.

Might have been a naive mistake on my part but I must say this new API comes with somewhat of a learning curve. Perhaps stressing the url-encoding requirement in the documentation might prevent others from having this problem in the future.