I am a developer at twivert . com
Twivert users are signned in using twitter.
For the past 15 hours or so we are getting continuous 401 unauthorizd
This error is happening for all requests to the API from our
Our users are not able to sign in.
Please advice on what should be done.
On Dec 29, 11:45 am, Raffi Krikorian <ra...@twitter.com> wrote:
> hi eric.
> yup - you've hit it right on the head. one of the main initiatives in us
> starting to version our API is so that we can really consolidate and make
> our error codes consistent. unfortunately, for legacy compatibility
> reasons, we can't change the second case to have a 402 error and we will
> have to keep it as a 401.
> what you could do is parse the response that comes back in the 401, however.
> in the case that your password is wrong, the error should be
> "Could not authenticate you."
> for basic auth and OAuth. the second case has an error of
> "Not authorized"
> On Mon, Dec 28, 2009 at 3:38 PM, Eric Marcoullier @ Gnip <
> e...@marcoullier.com> wrote:
> > We're trying to build some logic into our data collector and we've
> > been fighting with an issue for a while involving the 401
> > "Unauthorized" error code.
> > There are two instances where I can get this response
> > 1) Bad credentials. I try to log in with an invalid username or
> > password.
> > 2) I don't have access to a specific user's private account.
> > The former can be a real problem for a user. I changed my password a
> > few weeks ago and forgot that I was using it for whitelisted REST API
> > access. Querying three times in rapid succession with a bad password
> > causes a temporary lockdown of a user's account. I was querying once
> > per second and locked the account for a five days. This is an account-
> > level issue and the proper way to deal with this from our perspective
> > is to immediately sleep the poller for 30 minutes and send an alert
> > about bad credentials.
> > This is completely different than if someone I'm following has taken
> > their account private. In this case, sleeping for 30 minutes (or any
> > amount of time, really) is overkill. Unless I'm querying for a single
> > person over and over, there's no reason to pause before moving onto
> > the next rule that I'm querying for.
> > Unfortunately, we have no way to disambiguate between the two 401s and
> > we're forced to either lock someone's account (ignoring 401s) or
> > severely reduce their polling efficiency (acting on 401s).
> > Best case would be to break these two error conditions out into
> > separate error codes. Perhaps a 401 for bad credentials and a 402 for
> > lack of authorization for a specific piece of content.
> > Please let know if I've overlooked something that would help me
> > disambiguate the use cases in the current system.
> > Thanks!
> > Eric
> Raffi Krikorian
> Twitter Platform Teamhttp://twitter.com/raffi