[twitter-dev] Intermittent 401 errors calling access_token

[Marc Mims]

I have an ongoing problem with 401 Unauthorized errors calling 
access_token after the user has successfully authorized the app.  It 
happens on a small percentage of calls, but frequently enough (usually 
several times per day) to be quite annoying and leads to user 
complaints.

I've provided the full transaction chain for one of the failed 
authorizations below, eliding identifying values.

You can see from the timestamps in the response headers that entire 
chain was completed it a reasonable amount of time.  I notice a 14 
second difference between the Date and Client-Date headers.  I've 
verified that our server clock is accurate with NTP.

Also note that the final 401 response has no explanation in the body 
(Content-Length: 1).  Whenever I'm able to force a 401 response (e.g., by 
calling access_token with already used request tokens) I get some 
failure explanation in the response body.

Is this a problem on my end or does this indicate a problem on Twitter's 
end?

Is there anything else I can provide to help diagnose this problem?

-Marc


### request_token request ###

GET https://api.twitter.com/oauth/request_token
Authorization: OAuth 
oauth_callback=http%3A%2F%2Felided,oauth_consumer_key=elided,oauth_nonce=i%2FfgTr7omYPt4AAWfD4Bby35UlQ,oauth_signature=48U6n6FRtFYx1iKqtmE36ZMTvdw%3D,oauth_signature_method=HMAC-SHA1,oauth_timestamp=1293104523,oauth_version=1.0
User-Agent: Net::Twitter/3.14002 (Perl)
X-Twitter-Client: Perl Net::Twitter
X-Twitter-Client-URL: http://search.cpan.org/dist/Net-Twitter/
X-Twitter-Client-Version: 3.14002


### request_token response ###

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Connection: close
Date: Thu, 23 Dec 2010 11:42:18 GMT
Pragma: no-cache
ETag: 9a7fe06568d1d60ff0edf37ea73d3517
Server: hi
Vary: Accept-Encoding
Content-Length: 145
Content-Type: text/html; charset=utf-8
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Last-Modified: Thu, 23 Dec 2010 11:42:18 GMT
Client-Date: Thu, 23 Dec 2010 11:42:04 GMT
Client-Peer: 128.242.245.253:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Client-SSL-Cert-Subject: 
/serialNumber=Zys2dJJ09EPoEVGXYtegIdxG3OZtEOib/C=US/O=*.twitter.com/OU=GT57932074/OU=See
 www.rapidssl.com/resources/cps (c)10/OU=Domain Control Validated - 
RapidSSL(R)/CN=*.twitter.com
Client-SSL-Cipher: DHE-RSA-AES256-SHA
Client-SSL-Warning: Peer certificate not verified
Set-Cookie: k=67.225.143.68.1293104538943773; path=/; expires=Thu, 30-Dec-10 
11:42:18 GMT; domain=.twitter.com
Set-Cookie: guest_id=129310453895441949; path=/; expires=Sat, 22 Jan 2011 
11:42:18 GMT
Set-Cookie: 
_twitter_sess=BAh7CDoPY3JlYXRlZF9hdGwrCExlCRMtAToHaWQiJWJjODZjZmI5Mjc2ZTI1%250AY2ZhZWQ0YTQ2YjA5YTRlODZlIgpmbGFzaElDOidBY3Rpb25Db250cm9sbGVy%250AOjpGbGFzaDo6Rmxhc2hIYXNoewAGOgpAdXNlZHsA--e77d2ea105e6097a1a23f2d3ab34e11f6581b161;
 domain=.twitter.com; path=/
Status: 200 OK
X-Revision: DEV
X-Runtime: 0.02151
X-Transaction: 1293104538-2524-9007

oauth_token=3G61MtFOzOwUCzFCZ0i7qlBLCNg3GeSBq6JomuChgoauth_token_secret=mgKM5MRmz5tcJwfDsJMASQ4kuSgDIFTuHc83uNmCAYoauth_callback_confirmed=true


### redirect user to Twitter ###

https://api.twitter.com/oauth/authorize?oauth_token=3G61MtFOzOwUCzFCZ0i7qlBLCNg3GeSBq6JomuChg

### user returned to OAuth callback ###

'oauth_token' = '3G61MtFOzOwUCzFCZ0i7qlBLCNg3GeSBq6JomuChg',
'oauth_verifier' = 'kZRqjesOVETmL9Sf7k3NnGRItnKXFm525UN8D6GG7DE'


### access_token request ###

GET https://api.twitter.com/oauth/access_token
Authorization: OAuth 
oauth_consumer_key=elided,oauth_nonce=JhQ00FmtBqcq6wo%2Be%2F60vD%2F8G28,oauth_signature=qb1M%2F9xFvViKpoX8q%2BU%2Bl%2B2UTog%3D,oauth_signature_method=HMAC-SHA1,oauth_timestamp=1293104564,oauth_token=3G61MtFOzOwUCzFCZ0i7qlBLCNg3GeSBq6JomuChg,oauth_verifier=kZRqjesOVETmL9Sf7k3NnGRItnKXFm525UN8D6GG7DE,oauth_version=1.0
User-Agent: Net::Twitter/3.14002 (Perl)
X-Twitter-Client: Perl Net::Twitter
X-Twitter-Client-URL: http://search.cpan.org/dist/Net-Twitter/
X-Twitter-Client-Version: 3.14002

### access_token response ###

HTTP/1.1 401 Unauthorized
Cache-Control: no-cache, no-store, must-revalidate, pre-check=0, post-check=0
Connection: close
Date: Thu, 23 Dec 2010 11:42:59 GMT
Pragma: no-cache
Server: hi
Vary: Accept-Encoding
Content-Length: 1
Content-Type: text/html; charset=utf-8
Expires: Tue, 31 Mar 1981 05:00:00 GMT
Last-Modified: Thu, 23 Dec 2010 11:42:59 GMT
Client-Date: Thu, 23 Dec 2010 11:42:44 GMT
Client-Peer: 128.242.245.221:443
Client-Response-Num: 1
Client-SSL-Cert-Issuer: /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
Client-SSL-Cert-Subject: 
/serialNumber=Zys2dJJ09EPoEVGXYtegIdxG3OZtEOib/C=US/O=*.twitter.com/OU=GT57932074/OU=See
 www.rapidssl.com/resources/cps (c)10/OU=Domain Control Validated - 
RapidSSL(R)/CN=*.twitter.com
Client-SSL-Cipher: DHE-RSA-AES256-SHA
Client-SSL-Warning: Peer certificate not verified
Set-Cookie: k=67.225.143.17.1293104579798347; path=/; expires=Thu, 

[twitter-dev] Intermittent 401 Errors

[Dewald Pretorius]

Since late yesterday (May 10), I've been getting intermittent 401
Could not authenticate you errors.

This is on Twitter accounts and code that have been working for a very
long time. My code has not changed, and there is nothing wrong with
the Twitter accounts either. They are not suspended, or limited, and
the connection for my app is firmly present in the Connections tab.

One one call (I've validated this on mentions.json,
direct_messages.json, and friends_timeline.json) it would work and
give me a 200 with the data. On the very next call I get a 401 Could
not authenticate you. There is no discernable pattern.

Please don't ask me to capture TCP dumps. This is my live app, and I
am not going to mess with it to debug the API.