It seems like there should be some solution that lets me use basic auth for those little scripts. Maybe tell Twitter IP's from which I want to be able to use basic auth? It would be a bit of a pain since most people have dynamic IP's, but it would be better than nothing, and it would at least make it simple to run basic auth scripts on my VPS (which obviously has a static IP).
For Ruby-minded folks there's http://github.com/marcel/twurl which is effectively curl that uses OAuth - though it isn't the same.
John Nunemaker wrote a tutorial on how to get get up and running with OAuth pretty quickly (though it is for the Ruby/Rails audience) http://railstips.org/blog/archives/2009/03/29/oauth-explaine... .
I'll admit getting started with OAuth takes some time to ramp up at first, but that ramp up time gets smaller each subsequent app.
Wrote this when I was drunk to prove a point.
If they had just upgraded to OAuth 2.0 like Facebook recently launched, I'd be happy.
Facebook's OAuth can be done in like 10-20 lines of code. Twitter's takes like 100 (in PHP+Curl).
(essentially OAuth 2.0 just relies on https SSL instead of directly encrypting tokens via code before they are sent)
However in Ruby/Rails OAuth isn't that bad using http://twitter.rubyforge.org/ . And aside from a couple hiccups, I haven't had any problems with http://code.google.com/p/oauthconsumer/wiki/UsingOAuthConsum... on iPhone/iPad (I'm using the Browser redirect and re-launching the application from a custom application protocol).
Is there an actual reason to use xAuth over OAuth aside from having to put users through the trouble of re-authenticating? You have to have special permission from Twitter to use xAuth but who knows how easily they hand it out.
Reading the API mailing list it sounds like Twitter is granting xAuth access on a 1-2 week timeline. Though that may be based on the size of the email queues.
Rather than switching to OAuth, I'm tempted to just write a mechanize script to make posts using the web interface. Has anybody tried this approach?
Sure, you might just be able to create a new user and key if you get banned but this still gives them one more tool and a better picture of who is sending what over their network.
See the section in the relevant RFC:
Otherwise, no, I don't see it. I know that I'm less inclined to write a little hack to work with Twitter without basic auth.
The migration to OAuth 2 will be interesting though. All the existing clients will have the right kind of structure to plug in drop in a replacement flow, but I bet there will still be a bunch of complaints. "OMG I don't want to use HTTPS! This is so hard! Who cares that I can use curl to debug now, I want programming to be drag and drop." Haters gonna hate.
But your argument still doesn't explain why Twitter's supported service still uses xAuth. Or Twitterrific (and they have a significant market share). What is blocking them from migrating from Basic to non-xAuth OAuth?
In that case you would use Out-of-band/PIN Code Authentication. See http://dev.twitter.com/pages/auth_overview.
For Pythonistas, my little Twitter API script uses tweepy.py. Thanks to http://jmillerinc.com/2010/05/31/twitter-from-the-command-li... for the steps involved. As an exercise, you could scrape the required PIN with beautifulSoup or similar code to eliminate one step.
Generally speaking though, this is a great move by Twitter in my opinion. I'm always a bit concerned when a 3rd party website asks for a username and password. In some cases I no longer provide credentials when I know a certain service provides oauth.
It might not be as easy for non-web based applications, but I'm sure things will improve in the long run.
xAuth seems like it'd work, but, as stated in the article, that involves me going through some hoops to get back to this level of security. woo.