4 ms·

@twitterapi's countdown to Basic Auth removal

16 points by twapi 16y ago

adrinavarro 16y ago
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.
- _pius 16y ago
  This is a great move for Twitter. If Twitter's going to be a serious platform, it needs to stop requiring me to hand my password to every Tom, Dick, and Harry app that I want to try out. That's what oAuth accomplishes.
  - adrinavarro 16y ago
    The point was to encourage users to only use oauth. They could allow basic auth only on a conscious opt-in process by the user (assume that I want to write a bot that sends DM to my users, I don't want to mess with oauth just when I can drop my twitter password in the curl code, but I can log in to the twitter website to enable basic auth in this case). I really see the point of using oauth for almost any web-based apps, and now also for desktop-based ones. Adium does it pretty well (but one day the twitter support broke and I've been using Tweetie/Echofon since then). But it's still about access complexity: big apps have still months to rework functionality using basic auth, but in some cases, oauth is just hellish. I repeat myself, yes. Please: opt-in, twitter, we need it.
- steveklabnik 16y ago
  This comment sounds really assholish. I apologize in advance. This is why libraries exist. You shouldn't be implementing OAuth yourself.
  - aschobel 16y ago
    UX, not libraries seems to be the bigger barrier for OAuth.
    - steveklabnik 16y ago
      Isn't the UX really straightforward for this by now? It's a "log in with Twitter" button. That's it.
      - aschobel 16y ago
        Was thinking more for Mobile / Desktop apps, but I see that xAuth support is fully out which should streamline things http://twitter.com/twitterapi/status/9702051031 http://twitter.com/twitterapi/status/9702051031
  - archgrove 16y ago
    And importing a new library into my codebase is a non-trivial activity. I need to vet it, ensure it will be supported and updated, and that well, it actually works. It makes Twitter implementation from "pretty much trivial in any language/device under the sun" into "Pain in the ass". I don't mind supporting new APIs when they offer a solution to a real problem. As I've asked in my other comment, how many people have really lost their credentials via basic auth? Edit: I can't seem to reply to steveklabnik's post below, so I do it inline by emphasising importing a new library is a non-trivial activity. I'm afraid that mass importing of external code into my projects is not something I undertake lightly; unless it's a platform supported (or very widely used) library, it requires a reasonable amount of vetting to ensure that it a) Works b) Does't break anything else c) will continue to work in the future. My question remains: Why? What is the insanely pressing need to move to OAuth when users don't really seem to care and I can't find any evidence that it's been a real security problem? I completely agree that it's nicer in theory, but as mentioned in my other post, I don't actually see that it's any more secure. Unless I'm being highly dense, it would fall to a completely trivial quazi-social engineering hack in almost all end user cases.
    - steveklabnik 16y ago
      Have you actually done an OAuth integration yet? It could just be that I happened upon great support, but adding it to an app was just "require this library, update a config option, add a different link here and there." It was half a dozen steps, tops. And OAuth is a solution to a real problem. I don't want to provide my username/password to people who aren't Twitter.
    - steveklabnik 16y ago
      To reply to your edit, which is strange... I can see the "reply" link to myself. I guess we have different opinions on libraries. I come primarily from Ruby, where testing is heavily emphasized. I don't mind adding stuff to my app because I'm constantly testing it against things breaking. In addition, most libraries come with their own tests, so I can verify for myself that libraries work. The whole reason I use libraries is that they're a black box. I shouldn't have to worry if the library is broken or not, because they should be working. Maybe I've only used high quality libraries, but I can't remember the last time I came across a library bug. Anyway, I don't have any stats to back things up, but users do care. "Login via Twitter" is so much nicer than "put in your twitter name and password." I'd be very hesitant to do the second, but not the first.
  - barrkel 16y ago
    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.
    - deleted 16y ago
      [deleted]
    - steveklabnik 16y ago
      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/ 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.
  - kwamenum86 16y ago
    Why not implement OAuth yourself? It is pretty straightforward. There aren't really any edge cases to handle.
    - steveklabnik 16y ago
      I would if I had to, but I don't like re-inventing the wheel. Especially if the wheel is pretty straightforward... I'd rather let someone else do the work.
- MichaelApproved 16y ago
  There are options besides breaking all the existing code. Rate limit the basic API more or create an option to allow it per account. So many old apps will just be abandoned now.
- sharkbrainguy 16y ago
  You can switch to xAuth, if you don't want to mess with oauth. It's somewhere in the middle between basic and o http://dev.twitter.com/pages/auth#browser-less-apps http://dev.twitter.com/pages/auth#browser-less-apps
- jcapote 16y ago
  Using something like http://github.com/mbleigh/twitter-auth http://github.com/mbleigh/twitter-auth is actually easier than setting up a twitter app to use basic auth, imo.
adrianwaj 16y ago
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.
deleted 16y ago
[deleted]
archgrove 16y ago
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 16y ago
  Subscribe to the Twitter developer lists. They have solutions for platforms without a browser.
  - archgrove 16y ago
    OK, having researched, I presume you're refering to the XAuth stuff http://dev.twitter.com/pages/auth#browser-less-apps 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).
  - Tichy 16y ago
    My experience with open source Ruby solutions was mixed. It still is a vastly more complex problem than just being able to use my programming languages inbuilt http functionality.
Zev 16y ago
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.

16 points by twapi 16y ago

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.

_pius 16y ago
This is a great move for Twitter. If Twitter's going to be a serious platform, it needs to stop requiring me to hand my password to every Tom, Dick, and Harry app that I want to try out. That's what oAuth accomplishes.
- adrinavarro 16y ago
  The point was to encourage users to only use oauth. They could allow basic auth only on a conscious opt-in process by the user (assume that I want to write a bot that sends DM to my users, I don't want to mess with oauth just when I can drop my twitter password in the curl code, but I can log in to the twitter website to enable basic auth in this case). I really see the point of using oauth for almost any web-based apps, and now also for desktop-based ones. Adium does it pretty well (but one day the twitter support broke and I've been using Tweetie/Echofon since then). But it's still about access complexity: big apps have still months to rework functionality using basic auth, but in some cases, oauth is just hellish. I repeat myself, yes. Please: opt-in, twitter, we need it.
steveklabnik 16y ago
This comment sounds really assholish. I apologize in advance. This is why libraries exist. You shouldn't be implementing OAuth yourself.
- aschobel 16y ago
  UX, not libraries seems to be the bigger barrier for OAuth.
  - steveklabnik 16y ago
    Isn't the UX really straightforward for this by now? It's a "log in with Twitter" button. That's it.
    - aschobel 16y ago
      Was thinking more for Mobile / Desktop apps, but I see that xAuth support is fully out which should streamline things http://twitter.com/twitterapi/status/9702051031 http://twitter.com/twitterapi/status/9702051031
- archgrove 16y ago
  And importing a new library into my codebase is a non-trivial activity. I need to vet it, ensure it will be supported and updated, and that well, it actually works. It makes Twitter implementation from "pretty much trivial in any language/device under the sun" into "Pain in the ass". I don't mind supporting new APIs when they offer a solution to a real problem. As I've asked in my other comment, how many people have really lost their credentials via basic auth? Edit: I can't seem to reply to steveklabnik's post below, so I do it inline by emphasising importing a new library is a non-trivial activity. I'm afraid that mass importing of external code into my projects is not something I undertake lightly; unless it's a platform supported (or very widely used) library, it requires a reasonable amount of vetting to ensure that it a) Works b) Does't break anything else c) will continue to work in the future. My question remains: Why? What is the insanely pressing need to move to OAuth when users don't really seem to care and I can't find any evidence that it's been a real security problem? I completely agree that it's nicer in theory, but as mentioned in my other post, I don't actually see that it's any more secure. Unless I'm being highly dense, it would fall to a completely trivial quazi-social engineering hack in almost all end user cases.
  - steveklabnik 16y ago
    Have you actually done an OAuth integration yet? It could just be that I happened upon great support, but adding it to an app was just "require this library, update a config option, add a different link here and there." It was half a dozen steps, tops. And OAuth is a solution to a real problem. I don't want to provide my username/password to people who aren't Twitter.
  - steveklabnik 16y ago
    To reply to your edit, which is strange... I can see the "reply" link to myself. I guess we have different opinions on libraries. I come primarily from Ruby, where testing is heavily emphasized. I don't mind adding stuff to my app because I'm constantly testing it against things breaking. In addition, most libraries come with their own tests, so I can verify for myself that libraries work. The whole reason I use libraries is that they're a black box. I shouldn't have to worry if the library is broken or not, because they should be working. Maybe I've only used high quality libraries, but I can't remember the last time I came across a library bug. Anyway, I don't have any stats to back things up, but users do care. "Login via Twitter" is so much nicer than "put in your twitter name and password." I'd be very hesitant to do the second, but not the first.
- barrkel 16y ago
  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.
  - deleted 16y ago
    [deleted]
  - steveklabnik 16y ago
    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/ 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.
- kwamenum86 16y ago
  Why not implement OAuth yourself? It is pretty straightforward. There aren't really any edge cases to handle.
  - steveklabnik 16y ago
    I would if I had to, but I don't like re-inventing the wheel. Especially if the wheel is pretty straightforward... I'd rather let someone else do the work.
MichaelApproved 16y ago
There are options besides breaking all the existing code. Rate limit the basic API more or create an option to allow it per account. So many old apps will just be abandoned now.
sharkbrainguy 16y ago
You can switch to xAuth, if you don't want to mess with oauth. It's somewhere in the middle between basic and o http://dev.twitter.com/pages/auth#browser-less-apps http://dev.twitter.com/pages/auth#browser-less-apps
jcapote 16y ago
Using something like http://github.com/mbleigh/twitter-auth http://github.com/mbleigh/twitter-auth is actually easier than setting up a twitter app to use basic auth, imo.

adrianwaj 16y ago

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.

deleted 16y ago

[deleted]

archgrove 16y ago

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 16y ago
Subscribe to the Twitter developer lists. They have solutions for platforms without a browser.
- archgrove 16y ago
  OK, having researched, I presume you're refering to the XAuth stuff http://dev.twitter.com/pages/auth#browser-less-apps 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).
- Tichy 16y ago
  My experience with open source Ruby solutions was mixed. It still is a vastly more complex problem than just being able to use my programming languages inbuilt http functionality.

Zev 16y ago

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.