Twitter is up to their old antics of adding limits again, changing the API, and not telling developers as they do so. This morning Twitter released into production new limits around their verify_credentials() method in the API, only allowing users to verify their usernames and passwords through Twitter applications 15 times per hour. The problem is they didn’t tell any of the developers.
Sure enough, searching Twitter (the issues are intermittent), users are having password issues across the Twittersphere, wondering what is going on. It even affected my service, SocialToo, as we were using that method as a backup to verify users were indeed authenticated (and hence enabling us to notify them if they forgot to change their password with us). I e-mailed Twitter, and while very respectful as always, they seemed surprised at the issues we were having. When I asked if it had been announced anywhere they responded, “It wasn’t, no, because [we] assumed (apparently incorrectly) that people were only using this method occasionally.” There has still been no announcement by Twitter on the new limits.
Apparently, on June 29th, new text was added to the Developer API Wiki stating (regarding the verify_credentials() method in the API), “Because this method can be a vector for a brute force dictionary attack to determine a user’s password, it is limited to 15 requests per 60 minute period (starting from your first request).” The new limits don’t appear to have been put in place until this morning however, as that is when we noticed it at SocialToo.
So if you’re using the verify_credentials() method in your app, you may want to consider finding some other way to be sure your users are verified – I’m happy to announce it here. It now only takes a few runs by only a few apps to hit that limit for each user, and then users are stuck in the water until the next hour is up until apps begin to adapt to these new limits. That is why we’re seeing the issues across all of Twitter. According to Twitter, the best way is to look for a 401 response code returned in your API calls, as unauthenticated users will return as such when using the API. Twitter only suggests using verify_credentials() for new users. My conversation with Twitter ended with the suggestion from them, “Migrating to OAuth avoids the risk of a user changing her password, FWIW.”
FWIW, OAuth is still in beta and not yet suggested for use in Production. In their exact words, “For us, ‘beta’ really means ‘still in testing, not suitable for production use’.” In other words, use the Twitter API at your own risk.
You can follow the password problems as they happen in real-time on FriendFeed below:
http://friendfeed.com/search?q=password+service%3Atwitter&embed=1
