
@twitterapi's countdown to Basic Auth removal - twapi
http://www.countdowntooauth.com/
======
adrinavarro
I think it's a huge mistake. Mainly because when I write some random
application (bot or something) I really don't want to mess with oauth when I
just want to send a tweet. Plain.

Please, twitter. Don't.

~~~
steveklabnik
This comment sounds really assholish. I apologize in advance.

This is why libraries exist. You shouldn't be implementing OAuth yourself.

~~~
barrkel
What does your one-liner OAuth implementation for wget in bash look like?

Because that's what it's competing with, with Basic Authentication. A simple
POST to statuses/update.xml with HTTP username and password, a wget one-liner.

~~~
steveklabnik
I just said it was easy, not that it'd be one line. But most of the libraries
I've seen are pretty simple, see the oauth gem: <http://oauth.rubyforge.org/>

Three or four lines. Not the end of the world.

I agree that it's not as easy and simple as HTTP Authentication, but it's much
nicer from a user's standpoint.

------
archgrove
Edit: OK, I was wrong, as I'd hoped - you don't need a web browser. The rest
of my post stands unchanged as, regardless of my interpretation, it kills the
Twitter support I just wrote in less than an hour into one of my apps, and
renders it a multi-hour (if not day) redevelopment. I'll probably just kill
the feature.

This seems like a silly move: What was previously a very easy to target
platform is now much less easy. Was there a glut of user credential theft from
the basic authentication API that's caused this? Or is it the architectural
purists winning out over engineering pragmatism?

I'm not convinced that, on most devices, it will actually add any security
anyway. Consider iPhone application "EvilTwitter". User enables Twitter
support. I, evil developer, present a fake Twitter OAuth page. This looks
identical to the Twitter login page, carefully configured to hide most of the
Safari interface (as 99% of iPhone Safari embedders do). The user enters their
details, I steal them, the present a "Woops, wrong password" error. I redirect
them to the _real_ OAuth verification page. From here on, my application works
fine - the user just assumes they mistyped their details the first time (as
mobile device users do, well, continuously).

~~~
dangrossman
Subscribe to the Twitter developer lists. They have solutions for platforms
without a browser.

~~~
archgrove
OK, having researched, I presume you're refering to the XAuth stuff
<http://dev.twitter.com/pages/auth#browser-less-apps>.

How the frell is this any better than Basic auth for most users? I can only
see that 1) I don't have to store their password on my client and 2) it won't
be sent across the network plaintext.

This is useless. End users have no idea that I'm actually doing 1), and 2) has
never been a problem (HTTPS supports Basic auth fine for transport
encryption).

------
Zev
I've actually gone and removed Twitter support from an application I work on.
It was a small, fun /tweet command in Mobile Colloquy. I wrote it on a whim;
it came out to maybe 100 LOC (with proper error handling and formatting). More
time spent in NSURL{Connection, Request}'s docs than on anything else.

It was removed because it isn't worth the hassle of adding in an {O, X,
YetAnotherCharacter}Auth library. No, I don't have to write the code for it.
No, including _an entire library_ is not better than _100 lines of code_
(where the the authentication part amounts to one line if there isn't any
error handling).

Twitter's API went from being incredibly nice and easy to work with to having
a huge barrier in front of it as soon as they deprecated basic auth.

//edit: Note: I'm not trying to condemn OAuth. I'm sure it has its uses (even
if I'm not quite sure what they are). I just don't see how it is a benefit in
this particular case.

------
adrianwaj
My twitter client app uses Basic Auth yet doesn't store username or password,
it's all kept on client side. I won't be rewriting so it'll now be useless.

