Heya, this will definitely work for now. Thanks for the good idea. Eric
On Dec 29, 10: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
