Statuses/user_timeline.json works in 1.0 and not in 1.1

meezmicah · 2012-09-17T18:27:44.000Z

I am trying to migrate our application’s usage of the version 1 API to the 1.1 API. The exact same request to read the user_timeline that works in the version 1 API fails in the 1.1 API with an Authentication error. I AM POSITIVE that my Signature base string and Authorization header match identically to the ones I generate using the OAuth tool on this site. I’ve even plugged in the exact nonce and timestamp used by the OAuth tool on this site to verify that my Authorization header and signature are IDENTICAL.

Something else must have changed with the 1.1 parsing of the authentication header. Can someone clarify precisely what has changed?

episod · 2012-09-17T19:53:25.000Z

I would verify that you’re actually being identified as authenticated traffic on your 1.0 calls to statuses/user_timeline – in 1.0, we throw you a bone if your auth is bad and the request could otherwise be considered in an unauthenticated context. When this happens, we pass you an X-Warning header letting you know and you can also note the rate limiting headers indicating it’s an unauthenticated request.

API v1.1’s OAuth is indeed stricter than 1.0’s on a whole, however as far as statuses/user_timeline is concerned, the strict API v1.1 OAuth implementation is also present on 1.0’s endpoint.

Are you able to make other authenticated calls to v1.1 endpoints, beginning with the simplest like https://api.twitter.com/1.1/account/verify_credentials.json ?

meezmicah · 2012-09-17T20:18:18.000Z

Below is the response header…it doesn’t contain the X-Warning but I do see the rate limiting header. What is wrong with the Authentication?

{X-RateLimit-Limit: 150
X-RateLimit-Remaining: 147
X-RateLimit-Reset: 1347913247
X-RateLimit-Class: api
Pragma: no-cache
Status: 200 OK
X-Transaction: a9edcaa74be1c74c
X-Frame-Options: SAMEORIGIN
Content-Length: 3529
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Content-Type: application/json;charset=utf-8
Date: Mon, 17 Sep 2012 20:13:43 GMT
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Last-Modified: Mon, 17 Sep 2012 20:13:43 GMT
Set-Cookie: guest_id=“v1:134791282354587048”; Expires=Wed, 17-Sep-2014 20:13:43 GMT; Path=/; Domain=.twitter.com
Server: tfe

}

episod · 2012-09-17T20:22:24.000Z

I’ll see with the team why it’s not sending you the X-Warning header in this case.

OAuth can go wrong for many reasons. I recommend reviewing the recommended troubleshooting steps to isolate some of the possibilities. Be sure and verify your system clock is in sync with ours and that the access token and other keys involved are still valid: [node:204]

meezmicah · 2012-09-17T20:31:48.000Z

If you can tell me specifically why this is failing that would be fantastic…the only thing I can think of is the timestamp, although this seems unlikely to me. Meanwhile I will visit your link and see if there’s anything else I’m missing.

meezmicah · 2012-09-18T13:59:59.000Z

Ok something else has to be wrong with this scenario. I just used the exact Authorization header from the OAuth tool to sign my request and I am still Unauthorized. I’ve even Reset the keys and reauthorized the application and still no luck.

episod · 2012-09-18T14:33:02.000Z

From the information you’ve given me, I can’t fully diagnose what’s specifically wrong in your implementation.

If you can’t get the verbatim examples provided by the OAuth tool to function properly, I would verify that you haven’t accidentally invalidated the access token you’re using.

meezmicah · 2012-09-18T14:50:34.000Z

Can you at least see what was wrong with the request detailed above where the rate limiting headers are present?

Not only did I Reset the application keys but I also re-authorized the application right before testing the request against the 1.1 api for the user_timeline. The access token/secret should not be invalid.

episod · 2012-09-18T15:02:18.000Z

If you can show me the following, I can better help you diagnose what’s wrong:

the OAuth signature base string you’re generating
the full URL you’re executing
all the HTTP headers you’re sending (including ones your environment may be sending)
the HTTP response headers you get back, along with the status line, message, and body of the response

As a last note – this happens rarely, but it does happen: occaisionally an application record can get kind of “wedged” in a state. As a last kind of precautionary measure, I would try creating a totally new application, then generating a totally new access token for that application and try a fresh request from the OAuth Tool or your code to account/verify_credentials

meezmicah · 2012-09-18T17:07:02.000Z

Ok I just deleted and recreated an application and re-authorized the application. My call to read the user_timeline works using 2 separate signing frameworks against the v1 api and BOTH FAIL against the v1.1 api. There has to be something else that’s required with the 1.1 api that is not present in the documentation. Could it be something to do with this all happening against a localhost url for receiving the callbacks right now? Would those tokens be different than the ones that would call back to a production url? Am I required to pass any oauth parameters in the url, in addition to the header for signing these requests?

episod · 2012-09-18T17:10:18.000Z

There isn’t anything magically different between the two. There must be something subtle going wrong – just as it usually is with OAuth problems. If you share the details I’ve asked for, it’s a lot easier to spot what might be wrong. 95% of the time, a problem with OAuth can be tracked back to how the signature base string is generated. The rest of the time it’s either a timestamp issue or a matter of encoding parameters in the query string that you aren’t supposed to, or not encoding parameters in the query string that you are supposed to, or some combination of the two.

Please share your signature base string, the full URL you’re actually executing, and the other details if you’d like more assistance.

meezmicah · 2012-09-18T17:39:00.000Z

https://api.twitter.com/1.1/statuses/user_timeline.json?user_id=288274156&count=15

GET&https%3A%2F%2Fapi.twitter.com%2F1.1%2Fstatuses%2Fuser_timeline.json&count%3D15%26oauth_consumer_key%3D32lqT2VK4WNNl7XVNMA%26oauth_nonce%3D1372564%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1347989787%26oauth_token%3D0lMBTWLB53Y75TORYk19vXHrJNL8LKQyrRTJeZvPs%26oauth_version%3D1.0%26user_id%3D288274156

Authorization: OAuth oauth_consumer_key=“32lqT2VK4WNNl7XVNMA”, oauth_nonce=“1372564”, oauth_signature=“Gq9tTQZaRAqdMrLNtLpkmdDQaKQ%3D”, oauth_signature_method=“HMAC-SHA1”, oauth_timestamp=“1347989787”, oauth_token=“0lMBTWLB53Y75TORYk19vXHrJNL8LKQyrRTJeZvPs”, oauth_version=“1.0”

The result:

401 Unauthorized

Headers:

{Content-Length: 63
Content-Type: application/json; charset=utf-8
Date: Tue, 18 Sep 2012 17:36:38 UTC
Server: tfe
}

Body Content:

{“errors”:[{“message”:“Could not authenticate you”,“code”:32}]}

episod · 2012-09-18T17:44:53.000Z

From that example, it looks like the oauth_token value you’re using isn’t an access token. Access tokens on Twitter typically are prepended with a user ID and “-” character. Perhaps you’re persisting a request token instead of an access token?

meezmicah · 2012-09-18T17:52:23.000Z

The token persisted is the one received after handing back the temporary token and verifier from the first callback. Why would that token work against the v1 API if it weren’t valid?

meezmicah · 2012-09-18T18:43:32.000Z

You are correct - I just re-stepped through the code and the previous token was being persisted. This was my mistake and a bug in the original code. The scary thing however is that the reason I wasn’t looking there was because that Access Token works fine to receive Tweets for a user against the v1 API.

episod · 2012-09-18T18:45:27.000Z

Glad you figured it out. The reason it works against the v1 API is because you’re being evaluated in an unauthenticated context when you’re providing the invalid credentials. If you were making calls to a v1 method that required authentication, you’d have run into the same issue.

carlspierre · 2012-10-31T15:51:23.000Z

I’m also having this same issue it works for v1 but not v1.1 my request is
GET /1.1/statuses/user_timeline.json?count=10&user_id=539179937&include_entities=true&include_rts=true&oauth_consumer_key=7eoNgvKyZmI1a6yrvRuxBQ&oauth_nonce=795323935&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1351698462&oauth_token=86362376-31W8MeZZnW72EIvBSOEn2q9Cs8U1fAROdDG0rFfbf&oauth_version=1.0&oauth_signature=ysLacYf3Re8qnpGrAgk%2FOQjOEtc%3D HTTP/1.1

and I’m using the correct auth-token.

wondering if I need to pass something differently

CubeTreeSync · 2012-11-06T00:04:12.000Z

Hi, I am having the same problem. There are no X-Warning headers in my v1 responses (see below)

When i use the v1 path, i get the following response (loaded in rdebug)
(rdb:1) e rsp
#<Net::HTTPOK 200 OK readbody=true>
(rdb:1) e rsp.to_hash
{“x-ratelimit-class”=>[“api”], “last-modified”=>[“Mon, 05 Nov 2012 23:56:50 GMT”], “content-length”=>[“18367”], “x-ratelimit-reset”=>[“1352161088”], “expires”=>[“Tue, 31 Mar 1981 05:00:00 GMT”], “content-type”=>[“application/json;charset=utf-8”], “x-transaction”=>[“16941c17fdc1b562”], “cache-control”=>[“no-cache, no-store, must-revalidate, pre-check=0, post-check=0”], “set-cookie”=>[“guest_id=v1%3A135215981030529778; Expires=Wed, 5-Nov-2014 23:56:50 GMT; Path=/; Domain=.twitter.com”], “status”=>[“200 OK”], “x-ratelimit-limit”=>[“150”], “x-frame-options”=>[“SAMEORIGIN”], “date”=>[“Mon, 05 Nov 2012 23:56:50 GMT”], “server”=>[“tfe”], “x-ratelimit-remaining”=>[“113”], “pragma”=>[“no-cache”]}

When using v1.1, i get this
(rdb:1) e rsp
#<Net::HTTPUnauthorized 401 Unauthorized readbody=true>
(rdb:1) e rsp.to_hash
{“content-length”=>[“63”], “content-type”=>[“application/json; charset=utf-8”], “server”=>[“tfe”], “date”=>[“Mon, 05 Nov 2012 23:58:17 UTC”]}
(rdb:1) e rsp.body
"{“errors”:[{“message”:“Could not authenticate you”,“code”:32}]}"

poptweep · 2013-11-15T00:11:57.000Z

I wish twitter could admit there is something awry with user_timeline at their end. So many people have this issue using the same code as they use for other requests, yet only these timelines fail.
Apart from home_timeline and user_timeline I have no issues writing requests for twitter. Please would someone at twitter double check this?