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
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:
> 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
> 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:
>> 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.*
-- 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.
On 9/4/10 11:05 PM, Dustin Shea at demonicpa...@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.
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.
> On 9/4/10 11:05 PM, Dustin Shea at demonicpa...@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.
-- 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.
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:
> 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:
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.
>> 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:
