Application-only authentication with GET search/tweets API v1.1


#1

After the retirement of REST API v.1, I am trying to use the GET search/tweets API v1.1 with application-only authentication.
Following the documentation (https://dev.twitter.com/docs/auth/application-only-auth), I have obtained a consumer key and a consumer secret for my application, then I have successfully issued a post request to get my bearer token from my key/secret pair. It worked at the very first attempt and now I have my bearer token, but when I add it to my GET request as an “Authorization” header, I get a 403 return code, with no further information than “Forbidden”.
The URL I am sending my requests to is:
https://api.twitter.com/1.1/search/tweets.json?q=[my_query]&lang=it&result_type=mixed&include_entities=1&count=100
with the following headers:
User-Agent: [my application’s name and version]
Authorization: Bearer [the bearer token I got from https://api.twitter.com/oauth2/token]
Accept-Encoding: gzip
What am I doing wrong? Please don’t tell me the GET search/tweets API does not support application-only authentication…


#2

search/tweets does support app-only auth. Maybe there’s something else about how you’re sending the bearer token that is invalid? Did you progamatically select the return value or did you copy and paste it? Make sure that there aren’t any extra characters tacked to the end of it (like a new line character).


#3

I am facing the exact same problem: Here is my wireshark dump: (I have tried a lot of other values in Content-Type without any luck! Is it supposed to be working this way? I am really frustrated to find how little doc is around it !!!

GET /1.1/search/tweets.json?count=1000&result_type=recent&q=$MMM HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Authorization: Bearer XXXXX%3DjvLxGrKir9lKhZllz6IOqDKzxlL8DY0UoU3GndaCz4
Accept: text/html,application/xhtml+xml,application/xml
Accept-Encoding: gzip, deflate
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Java/1.7.0_07
Host: dell
Connection: keep-alive


#4

A GET-based request shouldn’t have a Content-Type HTTP header. You’re also sending a Accept header that disincludes JSON, the response type you’re asking for – not likely the issue, but also strange.

Also, you’re not encoding the “$” in your query. “$” is a reserved character and API v1.1 is strict about valid HTTP 1.1. You’ll need to encode that as “%24” instead.

Also, try asking for a lower count value. The Search API doesn’t support a count value of 1000.

Here’s a very simple version that works:

GET /1.1/search/tweets.json?count=100&result_type=recent&q=%24MMM HTTP/1.1
User-Agent: curl/7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.5
Host: api.twitter.com
Accept: /
Authorization: Bearer xxxxxxxxx


#5

how can I pass this similar request in iOS (for user timeline) ? I have my access_token from oAuth. But I do not get any data back when I use https://dev.twitter.com/docs/api/1.1/get/statuses/user_timeline
https://api.twitter.com/1.1/statuses/user_timeline.json?screen_name=skillsusari&count=30


#6

Hi Taylor,

I copied and pasted the bearer token, but I am absolutely sure there are neither trailing spaces, new lines nor any other extra character.

My GET request is exactly as I posted it above and as I am posting it here again:
https://api.twitter.com/1.1/search/tweets.json?q=[my_query]&lang=it&result_type=mixed&include_entities=1&count=100
User-Agent: [my application’s name and version]
Authorization: Bearer [the bearer token I got from https://api.twitter.com/oauth2/token, copied and pasted with no extra characters]

Adding or removing the “Accept-Encoding” does not change anything. I always get a 403 “Forbidden” response in return. A “Forbidden” return message almost certainly means the problem is about authentication, don’t you think? Apparently it is very simple: a URL, two headers, the value of the authorization header has been provided by the Twitter API with no errors; so, what can be wrong?

The same query used to work without authentication with REST API v1 (obviously what is now the “count” query parameter was “rpp” then, but this is clearly not the problem).


#7

I’ve got one more element: if I voluntarily provide a wrong bearer token instead of the correct one, I get a different error message, “Unauthorized” instead of “Forbidden”.
So:
Wrong bearer token -> "Unauthorized"
Correct bearer token -> "Forbidden"
This means that the correct bearer token is recognized and authorized by the Twittter API, but for some reason I am not allowed to perform that query.
Again, what am I missing? I’ve done everything Twitter’s documentation asked me to do, and I’m performing a query that has been working for a long time with REST API v1.
I’m starting to think that REST API v1 had to be dismissed only when the authentication process required by REST API v1.1 was much more stable and better documented. It looks like it isn’t now.


#8

Can you share more of your queries and what the encoding looks like in them? API v1.1 is stricter about HTTP compliance. If you’re using characters like “#” and “(” or " " or “)” or “!” or “@” or “$” or “#” – or many other characters, there’s extra work you have to do to make sure that they are encoded correctly.


#9

No, Taylor, I’m not using any special character in my queries. For testing purposes, I’m using simple one-word queries. The exact URL of my query is:
https://api.twitter.com/1.1/search/tweets.json?q=Genialloyd&lang=it&result_type=mixed&include_entities=1&count=100


#10

Excuse me, Taylor and everybody, it was all my fault. I was forgetting the “?” before the query string! Of course it wasn’t working…
Feel free to insult me if you want. :slight_smile:


#11

hello

i have create the application and got the Consumer key,Consumer secret ,Access token and
Access token secret

i want to diaply my latest twitter feed on my website

now what to do

plz help


#12

hello,
i have connected twitter using apiv 1.1 but i am facing new problem
that is how to migrate apiv1.0 to apiv1.1. any answer

please help me !


#13

all is doing well for the best


#14

i m facing the same problem of migrate from api 1 to api 1.1…
what to do