Intermittent OAuth issue


#1

We’ve noticed a significant number of 401 responses over the past 24 hours while performing OAuth API requests. We believe the credentials and request construction to be valid, as retrying the request after some period of time tends to succeed. This code is relatively stable and hasn’t changed in a very long time.

There were at least two windows where this occurred, one starting at 2012-01-05 01:05:35 UTC and another at 2012-01-06 00:35:42 UTC. We suspend credentials on 401 so we don’t have information about how long the API was in this state.

Is anyone else experiencing this? Perhaps a known issue?

Thanks,
Kenny


#2

We’re aware of the heightened 401s; some underlying services are having lag issues that are causing the false expression of 401s. It’s unclear when this will be completely resolved, but it may be gradual.


#3

Thanks, Taylor. What’s the best way to monitor the resolution of this?


#4

I am seeing these as well and they started on 1/9/2012 and about 11pm (GTM).

With sporadic 401’s possible (I have seen this for brief windows before) how should an app determine if a user has actually revoked authorization vs. a temporary outage? I currently suspend only after seeing 401 errors over a period of 30 minutes, but that does not seem sufficient to cover all cases. What would you recommend?


#5

Generally, we do not reattempt requests that return 4xx errors. If the request is valid, but the server cannot fulfill it, a 5xx would be more appropriate and would cause our client code to retry the request after some period of time.


#6

Hi everyone,

We’re now tracking this issue within this issue: [node:4945] (attached to the thread).

Normally these types of conditions would be a 50X response, but the root cause here is somewhat awkwardly placed in the stack and results in the 401s that you’re seeing. Ultimately, this is similar to 502s you may experience where our servers have terminated the sequence of internal requests needed to evaluate a request early due to exceptional durations in processing.

There’s little you can likely do in the meantime to mitigate, besides ensuring that you don’t consider a spurious, non-continuous 401 error a total failure in authentication.


#7

I’ve been having this issue for the last 2 days or so. What’s been very strange for me is that I have 2 apps I have registered, one for production and one for development. I use a desktop and a laptop, both running identical copies of my dev environment. For the last 2 days, I’ve been getting 401 on my laptop when attempting to connect to the stream with the dev app credentials.

My desktop works just fine, using exactly the same code and oauth keys. What’s even more odd is that if I use the oAuth tool and try the curl code from the terminal on my laptop, it works as expected.


#8

When is this likely to be addressed? It’s getting quite irritating.


#9

It’s being addressed – just taking time to resolve and I do not yet have an ETA as to when this will be completely resolved.


#10

hopefully this will not continue in the future. and should be completed faster!


#11

Hi Folks,

We believe we’ve identified and resolved this issue this afternoon. Please reply below if you’re still running into spurious 401 Unauthorizeds that succeed when the request is replayed verbatim.


#12

I believe I’m still having this issue.

In front of me I have my macbook and my desktop. Both machines have identical dev environments. Both are using fresh checkouts of my app from git.

On my desktop, the app authenticates to the stream as normal. On my laptop, I get 401 responses. Is there specific information that I can provide between the two environments?


#13

If you’re getting persistent 401s from one of your machines, it’s likely not the same issue. If you’re able to replay the exact request you received a 401 for and have it end up being successful, it may be the same issue.

Are there any differences between the two environments? Server clock, OS/language/library versions?


#14

You’re right. Wasn’t the same issue. I’ve been banging my head against this for a couple days.

Thanks for mentioning the clocks. I glanced at the clock displays between the two machines and they were off. I have no idea why or when it changed, but the laptop clock was not set for automatic date/time anymore and was off. Soon as I re-enabled that, now its working just fine.

Thanks for mentioning that. It was the one variable that didn’t occur to me since I’m not in the habit of changing my clock settings.


#15

Seems that there’s still a 401 issue with oauth/request_token request. Tested with local installation and on server. Server uses GMT, local box uses EET time, both are synchronized with NTP.


#16

seems to be working fine for us now. Thanks for fixing this!


#17

Yes, thankyou :).


#18

Hi,
According to @hootsuite you guys are addressing the following issue in this tread: Since about at least 10 days when I start up Hootsuite on my iPad2 I get the message: ‘Invalid Twitter Credentials, your Twitter credentials seem to be out of date. Please re-authenticate. Connect to Twitter.’ When I do try to connect, the app either crashes or keeps udating without result and then crashes anyhow. Hootsuite still works great on my iPhone and powerbook.
Message Hootsuite: ##HootSuite_Help 11:44pm via HootSuite
@Sven_Seven Twitter has indicated this as a known issue, and they are working on a fix: ow.ly/8rDeA ^MA##
Please advice?
Sven


#19

It’s most likely an auth failure for another reason. Have you examined the response & requests you are making carefully for any kind of errors or inconsistencies?


#20

Our issue is resolved – however, applications are all written differently and it’s possible the iPad app you’re using can’t gracefully recover despite the issue being resolved. Work with @hootsuite support on steps to reinstall your application and so on.