On the demise of basic authentication.

[Taylor Singletary]

GOODBYE BASIC AUTH

On Tuesday, August 31st 2010 at 16:26:13 UTC, @raffi of @twitterapi/team pressed "the button" that shut basic auth down for good:

   >> set :rate_limit_api_basic_auth, 0 ; puts Time.now Tue Aug 31 16:26:13 +0000 2010 => nil

   @raffi - http://twitter.com/twitterapi/status/22634515958

   

And with that issued command, we all said goodbye to Basic Authentication.

Basic authentication was the easiest way to get started with the REST API. With that ease came many dangers, giving rise to the term "the password anti-pattern."

OAuth is obviously more complicated to implement. We'll continue to refine and evolve possible authorization options that present more frictionless user & developer experiences without sacrificing user, developer, & Twitter security.

A POEM

   "The time has come," the Walrus said,

   "To talk of many things:

   Of SHAs--and nonces--and signatures--

   Of timestamps--and tokens--

   And why the dance--

   And whether OAuth has wings."

A WAKE

But let us not go with OAuth in anger, but instead with laughter in our hearts.

We've curated some of our favorite tweets on the subject. Not all of them are polite. http://curated.by/episod/oauthpocalypse -- some of them are funny, others are sad, some are just informational. All are proof that the transition to OAuth effects everyone a little differently.

SOME ERRATA

Large-scale migrations are not without their issues, of course. We introduced this bug and will be fixing it as soon as we can.

* Non-authenticated resources return a 401 with authorization challenge once the IP-based rate limit is exhausted.

  - The correct behavior here is for us to return a 400.

  - This includes public resources like public_timeline, public lists, widgets, etc.

OTHER REMINDERS

* Use api.twitter.com/1/* for all REST API operations (excluding Search and OAuth). 

  - You will have unusual results otherwise & eventually your calls will fail

* Use search.twitter.com for all Search API operations

* Use api.twitter.com/oauth/* for all OAuth token negotiation operations

NOW LAUGH & RELAX.

[mikesouthern]

I'm finding it fairly hard to laugh and relax, to be honest.

I'm not a developer. I just use perl scripts to automate my twitter
feeds.

Receiving a notice telling me that the authentication process had
permanently changed, and receiving it 2 days AFTER the change had been
deployed, was not impressive.. And discovering that there was no
legacy basic authentication to keep hobbyists on track was equally
unimpressive.

Not only, from a user and a hobbyist perspective, a confusing lack of
info on the oauth principles as they relate to twitter but there is an
absolute lack of examples for some of the simple things we do such
as ... how DO I automate my twitter feed using a perl script for which
there is no access token, and where the requirement is that of ::duh::
automation. i.e. no user transaction to obtain a token.

I "get" oauth, and the need for it - at least from your perspective. I
just can't believe that you club-footed your way into a release
schedule without some legacy support.



On Aug 31, 6:39 pm, Taylor Singletary <taylorsinglet...@twitter.com>
wrote:
> *GOODBYE BASIC AUTH*

>
> On Tuesday, August 31st 2010 at 16:26:13 UTC, @raffi of @twitterapi/team
> pressed "the button" that shut basic auth down for good:
>
>    >> set :rate_limit_api_basic_auth, 0 ; puts Time.now Tue Aug 31 16:26:13
> +0000 2010 => nil

>    @raffi -http://twitter.com/twitterapi/status/22634515958

>
> And with that issued command, we all said goodbye to Basic Authentication.
>
> Basic authentication was the easiest way to get started with the REST API.
> With that ease came many dangers, giving rise to the term "the password
> anti-pattern."
>
> OAuth is obviously more complicated to implement. We'll continue to refine
> and evolve possible authorization options that present more frictionless
> user & developer experiences without sacrificing user, developer, & Twitter
> security.
>

> *A POEM*

>
>    "The time has come," the Walrus said,
>    "To talk of many things:
>    Of SHAs--and nonces--and signatures--
>    Of timestamps--and tokens--
>    And why the dance--
>    And whether OAuth has wings."
>

> *A WAKE*

>
> But let us not go with OAuth in anger, but instead with laughter in our
> hearts.
>
> We've curated some of our favorite tweets on the subject. Not all of them

> are polite.http://curated.by/episod/oauthpocalypse-- some of them are

> funny, others are sad, some are just informational. All are proof that the
> transition to OAuth effects everyone a little differently.
>

> *SOME ERRATA*

>
> Large-scale migrations are not without their issues, of course. We
> introduced this bug and will be fixing it as soon as we can.
>
> * Non-authenticated resources return a 401 with authorization challenge once
> the IP-based rate limit is exhausted.
>   - The correct behavior here is for us to return a 400.
>   - This includes public resources like public_timeline, public lists,
> widgets, etc.
>

> *OTHER REMINDERS*

>
> * Use api.twitter.com/1/* for all REST API operations (excluding Search and
> OAuth).
>   - You will have unusual results otherwise & eventually your calls will
> fail
> * Use search.twitter.com for all Search API operations
> * Use api.twitter.com/oauth/* for all OAuth token negotiation operations
>

> *NOW LAUGH & RELAX.*

[Dustin Shea]

There was plenty of notification on when Basic Auth was going to be discontinued.

>> user& developer experiences without sacrificing user, developer,& Twitter

>> - You will have unusual results otherwise& eventually your calls will

>> fail
>> * Use search.twitter.com for all Search API operations
>> * Use api.twitter.com/oauth/* for all OAuth token negotiation operations
>>
>> *NOW LAUGH& RELAX.*
>

--
This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission.

[Mike Southern]

On 9/4/10 11:05 PM, Dustin Shea at demoni...@gmail.com wrote:

> There was plenty of notification on when Basic Auth was going to be
> discontinued.

Dustin, I can't comment on what notification you received, and am glad you
received it.

I can only comment on the notification that *I* received: this was, on
9/2/10, addressed to the email addys associated with all 11 twitter
accounts, the message that 3 days earlier basic auth had been expired.

While I may be a perl hobbyist, in my professional life I do know how to
identify, open and read an email.

[Dustin Shea]

My notification may have been due to the fact that I've been a member of the Dev List for some time thus foresaw this coming and I think it was mentioned on the old Twitter API wiki. I took notice do to the fact I was working on a TCL twitter app for an IRC eggdrop bot that was using Basic Auth and was struggling and waiting for someone with more knowledge than I to write a TCL resource I could use. I also follow @twitterapi on twitter.

--

[Marc Mims]

* mikesouthern <gb1...@cox.net> [100904 19:56]:

> I'm not a developer. I just use perl scripts to automate my twitter
> feeds.

For perl devs, the move to OAuth is really quite easy, especially for
automated scripts.

Register an application at http://dev.twitter.com. Grab the consumer
key and secret, and the access token and secret.

use Net::Twitter;

my $nt = Net::Twitter->new(
traits => [qw/OAuth API::REST/],
consumer_key => $YOUR_CONSUMER_KEY,
consumer_secret => $YOUR_CONSUMER_SECRET,
access_token => $YOUR_ACCESS_TOKEN,
access_token_secret => $YOUR_ACCESS_SECRET,
);

$nt->update("Bob's your uncle!");

Need help? Just drop by #net-twitter at irc.perl.org.

-Marc

[mikesouthern]

Aha! Perfect!

Thankyou so much Marc.

I knew what I was looking for - the access token and secret. But on
Twitter I was looking at https://twitter.com/oauth_clients/details/xxxxx
- at that site I can only get consumer key/secret.

dev.twitter.com shows the button I was looking for and Bob is indeed
my Uncle.

Thanks again

On Sep 4, 11:40 pm, Marc Mims <marc.m...@gmail.com> wrote:
> * mikesouthern <gb1...@cox.net> [100904 19:56]:
>
> > I'm not a developer. I just use perl scripts to automate my twitter
> > feeds.
>
> For perl devs, the move to OAuth is really quite easy, especially for
> automated scripts.
>

> Register an application athttp://dev.twitter.com. Grab the consumer

[Chris Hunt]

> For perl devs, the move to OAuth is really quite easy

Not for me it's not.

I'm not trying to write a full-featured Twitter client, just trying to
get my event calendar app to send a few tweets to a particular
account. I don't need mega-high security, I just need it to work.

I've registered at http://dev.twitter.com, filling in everything
except the "callback URL", cos I don't know what that is.

With some to-ing and fro-ing, I've managed to collect the four key
values and put each into a perl variable in my config file. I have set
the access level to "Read and Write". I've installed Net::OAuth on my
machine, and I've tried sending a tweet like this:

my $tw = Net::Twitter::Lite->new(

traits => [qw/OAuth API::REST/],

consumer_key => $TWITCONSKEY,
consumer_secret => $TWITCONSSEC,
access_token => $TWITACCTOK,
access_token_secret => $TWITACCSEC,
);
my $result = $tw->update("$message");

It just comes back with "Read-only application cannot POST", even
though it isn't.

What do I do now?

[Tom van der Woerdt]

If you change the access level, the keys don't. You will have to create
new user credentials. There are multiple ways of doing this, the easiest
one being simply re-creating the application on dev.twitter.com, this
time with proper settings. A different option would be to revoke access
(Settings -> Connections) and then re-authorize.

Tom