Intermittent OAuth issue

A_S_T501 · 2012-09-01T11:55:23.000Z

A-S-T-501

richevebebedor · 2012-11-10T12:11:05.000Z

I’m having the same problem. I’m using ntwitter and passport-twitter in nodejs. I use passport to authenticate and authorize my users then when I get their tokens I use ntwitter to post update and use the twitter stream API, the stream API is working well. But when I tried posting tweets, it always boils down to this error message:

{ [Error: HTTP Error 401: Unauthorized, API message: {“errors”:[{“message”:“Could not authenticate you”,“code”:32}]}]
data: ‘{“errors”:[{“message”:“Could not authenticate you”,“code”:32}]}’,
statusCode: 401 }

node_knockout · 2012-11-11T06:45:28.000Z

Also seeing this with nTwitter intermittently. Sometimes it works, sometimes not.

node_knockout · 2012-11-11T06:48:14.000Z

Also seeing this with nTwitter…

adriaan_pelzer · 2012-11-14T21:43:00.000Z

Has this issue by any chance resurfaced?

I’ve been getting 401 responses when calling “oauth/acces_token” since late yesterday. I’ve tried resetting my app’s keys, changing apps altogether, and creating an app on a different account, to try and rule out all possibilities.

The server’s clock is correct (synced with ntp), and just to make sure it’s nothing in my code, I’ve replicated the issue with Matt Harris’s tmhOAuth (https://github.com/themattharris/tmhOAuth), using the “oauth_flow.php” example unchanged (https://github.com/themattharris/tmhOAuth-examples/blob/master/oauth_flow.php). Unchanged, except for my app’s credentials, of course.

Anyone seeing anything similar?

episod · 2012-11-15T15:34:35.000Z

Is the issue only occurring on oauth/access_token or also everywhere else?

adriaan_pelzer · 2012-11-15T15:41:32.000Z

I have more info on this.

It only happens when I move my app to an AWS instance (new IP address, same url). At first I assumed it was due to a reverse DNS lookup not working, because of incomplete DNS propagation, but it persisted for more than 48 hours.

This morning, I moved it back to the original server it was on, and all worked fine again.

Is it possible that DNS results for reverse lookups are cached, and checked to prevent ARP poisoning attacks, or similar? That would make sense.

If so, is there a way around this?

adriaan_pelzer · 2012-11-15T15:42:17.000Z

I’ve only seen it happen on oauth/access_token. While this was happening, I could still make successful user stream connections.

kotoproger · 2012-11-23T13:53:52.000Z

I have the same problem with one of my applications.

Digitalsmind · 2012-12-10T21:42:23.000Z

I have the same issue now. We had a server crash and now, no matter what we try we are getting 401 errors. We even had the folks who make the app look at it (we were with them ALL day trying things out) and they finally said… it’s a twitter issue.

We can connect to the API (via SSH) and the facebook and linkin API calls ALL work from the app.

I’ve tried all the stuff mentioned here… no luck…

Anyone figure this out yet?

brouits · 2013-02-06T14:19:01.000Z

i also have 401 Unauthorized reponses on several requests, almost all the time.
e.g: /1.1/users/show.json?screen_name=brouits leads to 401 Unauthorized response with headers following:

content-type: application/json; charset=utf-8
date: Wed, 06 Feb 2013 14:14:42 UTC
server: tfe
content-encoding: gzip

with /1.0/ i have no problem.

brouits · 2013-02-06T15:08:29.000Z

okay, my mistake. for /1.1/users/show.json i made a mistake in baseString generation (i used it with full url and query params, not just base url). see 9.1.2. Construct Request URL in oauth.net documentation.

NaorBiton · 2013-05-14T08:29:00.000Z

Huh, I just noticed this thread now,
I opened a thread about an issue that sounds very similar, but happens on POST ‘statuses/filter’ of the Streaming API.
https://dev.twitter.com/discussions/17580

We have spent a significant amount of time to trace the root cause of this, and we thought that perhaps there is something missing from our API calls which can make them pass all the time.
So far we haven’t managed to change anything that has any impact on how this works, and the service seems to come back up every now and then, but soon after we’re back to receiving 401’s.
I did find out that during “down time”, usually after 5- 7 connection retries (manual) we’re getting the stream to work.
We’re using the ‘ntwitter’ module for Node.js

Any help will be extremely appreciated. We can not go to production with this.

bryan_m · 2013-06-26T09:54:56.000Z

I know this is a old thread but I’m adding it here incase someone actually reads it. Since the change to API 1.1 and required OAuth with callbacks. I have seen entirely random 401’s when sending a post… I can do a few 200’s in a row then all of a sudden get hit with some 401’s for no reason, then all of a sudden the servers will then accept the updates for a while. Entirely random with no reason or valid code of why the error happens.

edit: and no, it’s not a rate limit issue.

Sulabh_Jain · 2013-06-28T17:53:09.000Z

I am running into similar issue where airbrake is showing 401 with Twitter not responding error message. Is that an expected behavior ? I am using oauth. This has been happening intermittently for last 2-3 weeks.

itsvipins · 2013-10-20T10:08:06.000Z

I am getting the same error {“errors”:[{“message”:“Could not authenticate you”,“code”:32}]}

chadmaughan · 2013-11-13T17:19:00.000Z

We’ve seen similar behavior.

It’s happened to us once before and is currently happening. When we deploy new code (unrelated to OAuth) to multiple AWS instances, it suddenly stops working. This is for both new authenticate requests and API connections with previously acquired access tokens.

Several weeks ago this happened on a deploy. A few days later it magically started working again with no code changes.

It has only affects a single deployment lane (i.e. works in dev, stage, but not in prod).

Our first thought was system times. That doesn’t appear to be the case.

Any one have any ideas?

Thanks in advance for your help!

episod · 2013-11-13T17:54:12.000Z

Do you know if you’re changing geographic regions at all, perhaps talking to a different Twitter data center than you typically do, one where maybe your application-related data isn’t as “hot” and ready? Do you know if your instances are aggressively caching DNS or other routing information potentially leading you to talk to servers that aren’t in active use? If you examine the raw requests, HTTP headers and all when requests fail do they more or less functionally identical to those sent that were functional?

Sokine199 · 2014-01-02T15:27:35.000Z

of conditions would be a 50X response, but the root cause here is ? 401s that you’re seeing. Ultimately, this is similar to 502s ?401 error a total failure in authentication. , , , , …

Sokine199 · 2014-01-02T15:28:32.000Z

last 2 days or so. What’s been very strange for me is that I have 2 apps I , using exactly the same code and oauth keys. What’s even more odd is that if I ?curl code from the terminal on my laptop, it works as expected. , , & tags