Re: [twitter-dev] Re: Basic Auth Deprecation
See Twurl: http://thechangelog.com/post/536535280/twurl-oauth-enabled-curl-for-the-twitter-api and http://github.com/marcel/twurl +Clint On Thu, Apr 29, 2010 at 9:47 PM, mcfnord wrote: > I think I know the answer to this question (YES), but I wanna clarify: > Everywhere in the docs that I see curl followed by credentials, > if the topic includes REST, that's an API that I will not be using > curl for, > because curl doesn't use oauth, so it cannot authenticate. > > i'll certainly know in 30 days if that's right. ;) >
[twitter-dev] Re: Basic Auth Deprecation
I think I know the answer to this question (YES), but I wanna clarify: Everywhere in the docs that I see curl followed by credentials, if the topic includes REST, that's an API that I will not be using curl for, because curl doesn't use oauth, so it cannot authenticate. i'll certainly know in 30 days if that's right. ;)
Re: [twitter-dev] Re: Basic Auth Deprecation
this is part of the oauth rewrite that we mentioned at chirp - we hope to be rolling it out soon. On Sat, Apr 17, 2010 at 7:17 AM, Lil Peck wrote: > On Sat, Apr 17, 2010 at 8:09 AM, sdesapio wrote: > > Classic ASP VBScript OAuth library and example project: > > http://scottdesapio.com/VBScriptOAuth/ > > > > :) > > > My hero! (Although I am still waiting for Twitter to complete its 2 > legged oauth.) > > > -- > Subscription settings: > http://groups.google.com/group/twitter-development-talk/subscribe?hl=en > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
On Sat, Apr 17, 2010 at 8:09 AM, sdesapio wrote: > Classic ASP VBScript OAuth library and example project: > http://scottdesapio.com/VBScriptOAuth/ > > :) > My hero! (Although I am still waiting for Twitter to complete its 2 legged oauth.) -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
[twitter-dev] Re: Basic Auth Deprecation
Classic ASP VBScript OAuth library and example project: http://scottdesapio.com/VBScriptOAuth/ :) On Apr 14, 11:16 am, Lil Peck wrote: > On Tue, Apr 13, 2010 at 11:01 PM, TJ Luoma wrote: > > I'm still unclear what people who use 'curl' will do after basic auth > > is deprecated. > > Likewise for those of us who have Classic ASP web apps that use > XMLHTTP > (http://asp.web.id/update-twitter-status-with-classic-asp-vbscript.html)! > > Will 2 leggedOauthwork for us? When will Twitter offer that? Will it > be as simple to integrate as is basic authentication? -- Subscription settings: http://groups.google.com/group/twitter-development-talk/subscribe?hl=en
Re: preserving consumer key secrecy (was: Re: [twitter-dev] Re: Basic Auth Deprecation)
Why not just distribute a key with it? The worst that happens is someone uses it in their app and it gets disabled and some people get pissed off at you. I have yet to hear of this happening to a Twitter application. If someone abuses your key and Twitter does not handle the situation well I will personally call Sarver to bitch. :-P Abraham On Thu, Apr 15, 2010 at 02:09, John SJ Anderson wrote: > On Wed, Apr 14, 2010 at 18:26, Raffi Krikorian wrote: > > yes, it could be a problem - however, there are known solutions to > > obfuscating and keeping your consumer key secret. not perfect, but > pretty > > good. maybe we can start a discussion around this? > > What's the known solution for an open-source Web-based application > that I want to distribute to the world[1]? "Make people get their own > key" is not an acceptable solution; neither is "proxy all requests > through your own web site and add the secret there". > > [1]: http://github.com/genehack/app-status-skein > > > john. > -- Abraham Williams | Developer for hire | http://abrah.am PoseurTech Labs | Projects | http://labs.poseurtech.com This email is: [ ] shareable [x] ask first [ ] private. -- To unsubscribe, reply using "remove me" as the subject.
Re: preserving consumer key secrecy (was: Re: [twitter-dev] Re: Basic Auth Deprecation)
> > yes, it could be a problem - however, there are known solutions to > > obfuscating and keeping your consumer key secret. __not perfect, but pretty > > good. __maybe we can start a discussion around this? > > What's the known solution for an open-source Web-based application > that I want to distribute to the world[1]? "Make people get their own > key" is not an acceptable solution; neither is "proxy all requests > through your own web site and add the secret there". I had the same question and was very gratified to find out that Raffi is in fact working on this very problem with the next draft of oAuth. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- mouse, n: A device for pointing at the xterm in which you want to type. -- To unsubscribe, reply using "remove me" as the subject.
preserving consumer key secrecy (was: Re: [twitter-dev] Re: Basic Auth Deprecation)
On Wed, Apr 14, 2010 at 18:26, Raffi Krikorian wrote: > yes, it could be a problem - however, there are known solutions to > obfuscating and keeping your consumer key secret. not perfect, but pretty > good. maybe we can start a discussion around this? What's the known solution for an open-source Web-based application that I want to distribute to the world[1]? "Make people get their own key" is not an acceptable solution; neither is "proxy all requests through your own web site and add the secret there". [1]: http://github.com/genehack/app-status-skein john.
Re: [twitter-dev] Re: Basic Auth Deprecation
yes, it could be a problem - however, there are known solutions to obfuscating and keeping your consumer key secret. not perfect, but pretty good. maybe we can start a discussion around this? people are going to need to start to move towards this method, and we are here to help you if you need it. ps. DO NOT COUNT ON THIS, but @anywhere is powered using a draft oauth 2.0 spec. we are not yet opening up those endpoints for public use because we reserve the right to switch them around to follow the spec a bit more closely. we will be opening this up for others to use, but we do not yet have a timeframe for it. we have to first fully deploy our oauth 1.0a rewrite. On Wed, Apr 14, 2010 at 3:22 PM, Josh Roesslein wrote: > I am all for oAuth replacing basic, but one of the remaining issues is > consumer keys. With 1.0 signing is required thus requiring > distributing keys with your application. We all know this is pretty unsafe > since any hacker could yank them out. > oAuth 2.0 does seem to solve a lot of the issues involving desktop > applications, but is still being drafted. So maybe holding off > basic auth depreciation until then might not be ideal, but I think it would > help make porting to oAuth a bit easier. > Just curious how soon can we expect 2.0 to be rolling out and if Twitter > has considered at all extending basic auth's lifetime. > > Thanks, > > Josh > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
I am all for oAuth replacing basic, but one of the remaining issues is consumer keys. With 1.0 signing is required thus requiring distributing keys with your application. We all know this is pretty unsafe since any hacker could yank them out. oAuth 2.0 does seem to solve a lot of the issues involving desktop applications, but is still being drafted. So maybe holding off basic auth depreciation until then might not be ideal, but I think it would help make porting to oAuth a bit easier. Just curious how soon can we expect 2.0 to be rolling out and if Twitter has considered at all extending basic auth's lifetime. Thanks, Josh
Re: [twitter-dev] Re: Basic Auth Deprecation
We're getting ready to release a few changes to our oauth implementation that will allow two legged oauth for public methods. On Apr 14, 2010, at 9:16 AM, Lil Peck wrote: On Tue, Apr 13, 2010 at 11:01 PM, TJ Luoma wrote: I'm still unclear what people who use 'curl' will do after basic auth is deprecated. Likewise for those of us who have Classic ASP web apps that use XMLHTTP (http://asp.web.id/update-twitter-status-with-classic-asp-vbscript.html )! Will 2 legged Oauth work for us? When will Twitter offer that? Will it be as simple to integrate as is basic authentication? -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
On Tue, Apr 13, 2010 at 11:01 PM, TJ Luoma wrote: > I'm still unclear what people who use 'curl' will do after basic auth > is deprecated. > > Likewise for those of us who have Classic ASP web apps that use XMLHTTP (http://asp.web.id/update-twitter-status-with-classic-asp-vbscript.html)! Will 2 legged Oauth work for us? When will Twitter offer that? Will it be as simple to integrate as is basic authentication? -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
OAuth was intended to facilitate inter-platform user account access without requiring actual usernames or passwords to be exchanged. This would allow platforms such as Twitter, Facebook, TwitPic, etc. to access each others user accounts while maintaining the privacy of that user's access credentials. Requiring OAuth for end-user client applications is somewhat of a misapplication of its intended purpose. Client apps aren't separate platforms, but extensions of the target platform. User credentials aren't being shared, but simply provided to the target platform (Twitter). No one but the user, his device's client, and Twitter are involved, and all three are trusted participants in the access credential exchange process. However, OAuth does provide some valuable side benefits such as application tracking, accounting, and control, and XAuth hides the cumbersomeness of exiting to a browser and retrieving and entering a PIN. XAuth simply makes the assumption that the end-user's Twitter client is at least as trustworthy as the end-user's web browser. As far as not storing actual username / password credentials in the client, that is neither here nor there with regards to OAuth. Practically every browser made offers to store your user access credentials when they recognize a user access authentication transaction. A user is free to record their access credentials anyway they want. The OAuth specification takes no stand on this, as it shouldn't. It's important to note that OAuth does not actually improve user credential security, or security of their accounts. It in fact opens the user up to phishing attacks with bogus challenges requesting access to sites to obtain their actual user credentials to those sites. Users could easily be lulled into providing this information without too much hesitation as they grow accustomed to this required practice with the apps they use. Personally, I think requiring OAuth for client apps serves little purpose since these apps collectively represent such a small part of Twitter's total traffic. It does however unnecessarily complicate the user access process to their accounts and could eventually compromise their account security. The claims that Basic Auth is insecure are totally false. Basic Auth when transmitted via https is quite secure. Millions of username/password credentials are securely exchanged over https everyday, including Twitter itself when accessed via the Twitter web client (I may be wrong, but I don't believe Twitter's own web client uses OAuth). On Wed, Apr 14, 2010 at 8:33 AM, Cameron Kaiser wrote: > > Why are you Twitter guys pushing xAuth so hard? Even for new desktop > > clients? Instead of recommending a proper oAuth flow with PIN or such? > > I understood its main purpose is to help legacy clients with > > transition, and new clients should do proper oAuth. > > I can tell you that there are many TTYtter users, including myself as we > speak, who tweet over ssh back to their server. There may not be a browser > for them to talk to. > > There are also users who use it not as a client, but as a command line > tool for cron jobs. > > xAuth, as I understand it, is for the browserless case. > > -- > personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- The steady state of disks is full. -- Ken Thompson > - > > > -- > To unsubscribe, reply using "remove me" as the subject. >
[twitter-dev] Re: Basic Auth Deprecation
OAuth has benefits all around for everybody. In addition to the benefits already mentioned: 1) For a web app like mine, it saves a TON of support workload with people who change their Twitter password, don't change it in my system, and then blame my system for not working because it's not able to access their Twitter account. 2) If your app has its own API, you'll quickly understand the need for OAuth and some form of control over the services that access your API. I just haven't had the time to put an OAuth server on my own API (have been too busy taking down my Christmas decorations these past week or three), but it's coming. You really get annoyed when spammers cram their crap into your system via ip-hopping proxies, and there's very little you can do about it apart from finding the shit and deleting it afterwards. -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
Response inline. On Wed, Apr 14, 2010 at 7:07 AM, Raffi Krikorian wrote: > again - overly dramatic. > > everything i said above still stands - it provides transparency into the > traffic that applications generate (potentially audit trails for users, > better ways to squelch spammy apps, etc.), as well as provides some security > in that user's passwords are not being sent in the clear. > > you can easily look for other examples of people using oauth for similar > situations - google is using oauth to allow applications access to mail, > etc. > For what it's worth: Speaking as a Googler, and as someone who is interested in user's safety and security overall, I'm thrilled to see the industry trend toward deprecation of stored credentials in favor of delegated authorization mechanisms. So thank you — on behalf of the industry — to Twitter for doing this. It's difficult/impossible to ensure the long-term safety and security of stored passwords required for standard basic auth, and it is similarly impossible to know for sure that a desktop application is either a) really a desktop application or b) really secure. A delegated authorization flow has the advantage in that it can be scoped to grant only specific narrow permissions (read twitter messages, read a calendar, check your email), but not others (delete your account, charge your credit card, read your web history, etc).Plus, authorization tokens can be revoked on a per-application basis on the server side if a third-party application goes rogue or is compromised in the future (or set to automatically expire). None of those things are easily possible with the traditional "master key" approach of stored passwords. While there are several evolving ways to get there — and I don't think we've collectively quite figured it all out yet (Raffi's post thinking about trust models for xauth is right on) — the general message of deprecating usernames and passwords in third-party apps is the right one for all of us, so I still applaud Twitter for taking a stand here, and expect and hope many others will follow. -DeWitt > > So basically you are saying Twitter wants a chokehold to block apps they >> don’t like which you don’t currently have with basic auth. >> >> Considering your recent purchase of a twitter client is that really a >> message you want to be spreading at the moment? >> >> How about leaving it up to end users to make the decision about which >> clients they do and don’t use to access twitter. Restricting all clients to >> oauth only is hardly going to give developers warm and fuzzy feelings that >> with a single keystroke a client can be banned instantly across the entire >> ecosystem. >> >> >> >> Or am I missing something? >> >> >> >> >> >> >> >> >> >> Cheers, >> >> Dean >> >> >> -- >> >> *From:* twitter-development-talk@googlegroups.com [mailto: >> twitter-development-t...@googlegroups.com] *On Behalf Of *Raffi Krikorian >> *Sent:* Wednesday, April 14, 2010 8:59 AM >> *To:* twitter-development-talk@googlegroups.com >> *Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation >> >> >> >> in my ideal world, nobody would have access to a user's password except >> twitter.com -- oauth provides a framework so end applications are not >> storing the actual password. people are notoriously bad with using the same >> password on lots of different sites. additionally, oauth provides twitter >> better visibility into the traffic coming into our system, so we can better >> shape traffic needs, we can provide auditing back to users on which >> applications are doing what actions on their behalf, etc. >> >> >> >> On Wed, Apr 14, 2010 at 5:39 AM, Dean 'at' Cognation dot Net < >> d...@cognation.net> wrote: >> >> But why is oauth better than basic for a desktop client? >> >> i understand it for the webapps but on a desktop client whats the >> point? >> >> Basically you are saying the desktop end user cant be trusted? Sorry >> but that doesn't make any sense. >> >> >> >> Please explain. >> >> >> Cheers, >> Dean >> >> >> >> On Apr 14, 1:15 am, Taylor Singletary >> wrote: >> >> > Basic auto being turned off means just that.. >> > >> > Desktop clients can implement xAuth as an alternative, where you do a >> > one-time exchange of login and password for an OAuth access token and >> > continue from there signing your requests and doing
RE: [twitter-dev] Re: Basic Auth Deprecation
If an app is trusted enough to have xAuth access, it should have the ability to do things like accept and reject followers for protected accounts via the API. An malicious xAuth application would already have full access to the user's account so it could already accept/reject followers through other means. It's the same with creating an account-there's no security justification for disallowing creating accounts for xAuth applications when the account settings are already available to xAuth applications that choose not to follow the rules and restrictions. Perhaps xAuth access should be granted only to people that have been authenticated with a high level of assurance-the same method you use for "verified" accounts and/or through some high-assurance certificate provider. For example, you could require xAuth developers to sign a token using their iPhone appstore/Symbian Signed/WinMo/Java Verified/High Assurance SSL certificate in order to prove their identities. And/or, charge a token amount of money for xAuth access so that you can verify identity somewhat via the credit card used. The problem with socializing security like you suggested is that it can only detect what end-users can detect. Chances are that all the users of a mythical Bieber & Ponies application are going to be relatively unsophisticated people that couldn't care less about security. And, also a malicious application can keep its bad behavior dormant for a long time until it builds up a large userbase and/or until some software update activates the bad behavior. -Brian From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, April 14, 2010 9:09 AM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: Basic Auth Deprecation we developed xauth specifically for that - mobile and desktop clients were complaining about usability problems when they have to bounce their users to a web browser. i'm well aware of the implications about xauth, and have blogged about it here: http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap would love to hear more comments as i formalize my thoughts around this! On Wed, Apr 14, 2010 at 6:15 AM, Jaanus wrote: Why are you Twitter guys pushing xAuth so hard? Even for new desktop clients? Instead of recommending a proper oAuth flow with PIN or such? I understood its main purpose is to help legacy clients with transition, and new clients should do proper oAuth. One argument I have seen is that oAuth has usability problems. I would like to see more substance around this statement beyond just developers thinking out loud. I have implemented oAuth in @cremeapp (ok, it uses in-app browser instead of separate, but otherwise it is the proper PIN flow) and not a single person has complained. I see from usage numbers that people breeze through the oAuth authentication just fine. I was expecting worse, but it's fine. It comes down to proper UI design and clarity of instructions. J On Apr 14, 1:15 am, Taylor Singletary wrote: > Basic auto being turned off means just that.. > > Desktop clients can implement xAuth as an alternative, where you do a > one-time exchange of login and password for an OAuth access token and > continue from there signing your requests and doing things in the > OAuth way. You'd no longer, as a best practice and one that I would > stress in the upmost even on a desktop client, store the login and > password beyond the xAuth access token negotiation step. If the token > were revoked you would then query for the login and password again and > so on and so on and also and also. > > Obtaining permission to use xAuth for desktop clients is as easy as > sending a well-identified and verbose note to a...@twitter.com. > > Basic auth had a good run. It's nearly time to say goodnight. > > Taylor > > > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. > > > Cheers, > > > Dean > > > -Original Message- > > From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius > > Sent: Tuesday, April 13, 2010 7:31 PM > > To: Twitter Development Talk > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > Could you please announce the hard turn off date somewhere on one of > > your Twitter blogs about a month ahead of time, so that we all have an > > official source to point our users to when we explain to them why > > we're converting everything
RE: [twitter-dev] Re: Basic Auth Deprecation
Raffi,
Twitter (corporate) are hardly in a position to start demanding the
rights to kill client apps at the moment.
But the sheep will head off to the slaughter without realizing whats
happening to them as they go. I think it's time for me to pass on
developing twitter apps. Anyone who wants to make me an offer for
www.MyPostButler.com <http://www.mypostbutler.com/> can do so now
otherwise I'll be putting it up for sale on one of the auction sites by
Friday.
Cheers,
Dean
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi
Krikorian
Sent: Wednesday, April 14, 2010 10:08 AM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Basic Auth Deprecation
again - overly dramatic.
everything i said above still stands - it provides transparency into the
traffic that applications generate (potentially audit trails for users,
better ways to squelch spammy apps, etc.), as well as provides some
security in that user's passwords are not being sent in the clear.
you can easily look for other examples of people using oauth for similar
situations - google is using oauth to allow applications access to mail,
etc.
So basically you are saying Twitter wants a chokehold to block
apps they don't like which you don't currently have with basic auth.
Considering your recent purchase of a twitter client is that
really a message you want to be spreading at the moment?
How about leaving it up to end users to make the decision about
which clients they do and don't use to access twitter. Restricting all
clients to oauth only is hardly going to give developers warm and fuzzy
feelings that with a single keystroke a client can be banned instantly
across the entire ecosystem.
Or am I missing something?
Cheers,
Dean
From: twitter-development-talk@googlegroups.com
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi
Krikorian
Sent: Wednesday, April 14, 2010 8:59 AM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Basic Auth Deprecation
in my ideal world, nobody would have access to a user's password
except twitter.com -- oauth provides a framework so end applications are
not storing the actual password. people are notoriously bad with using
the same password on lots of different sites. additionally, oauth
provides twitter better visibility into the traffic coming into our
system, so we can better shape traffic needs, we can provide auditing
back to users on which applications are doing what actions on their
behalf, etc.
On Wed, Apr 14, 2010 at 5:39 AM, Dean 'at' Cognation dot
Net wrote:
But why is oauth better than basic for a desktop client?
i understand it for the webapps but on a desktop client whats
the
point?
Basically you are saying the desktop end user cant be trusted?
Sorry
but that doesn't make any sense.
Please explain.
Cheers,
Dean
On Apr 14, 1:15 am, Taylor Singletary
wrote:
> Basic auto being turned off means just that..
>
> Desktop clients can implement xAuth as an alternative, where
you do a
> one-time exchange of login and password for an OAuth access
token and
> continue from there signing your requests and doing things in
the
> OAuth way. You'd no longer, as a best practice and one that I
would
> stress in the upmost even on a desktop client, store the login
and
> password beyond the xAuth access token negotiation step. If
the token
> were revoked you would then query for the login and password
again and
> so on and so on and also and also.
>
> Obtaining permission to use xAuth for desktop clients is as
easy as
> sending a well-identified and verbose note to
a...@twitter.com.
>
> Basic auth had a good run. It's nearly time to say goodnight.
>
> Taylor
>
>
>
>
>
> On Tuesday, April 13, 2010, Dean Collins
wrote:
> > Just so I understand this, applications running on the
desktop will still work correct? Basic functionality is only being
turned off for web apps correct? It's not like desktop apps will have to
start using oauth.
>
> > Cheers,
>
> > Dean
>
> > -Original Message-
> >
Re: [twitter-dev] Re: Basic Auth Deprecation
xauth is definitely useful for the browserless case. On Wed, Apr 14, 2010 at 6:33 AM, Cameron Kaiser wrote: > > Why are you Twitter guys pushing xAuth so hard? Even for new desktop > > clients? Instead of recommending a proper oAuth flow with PIN or such? > > I understood its main purpose is to help legacy clients with > > transition, and new clients should do proper oAuth. > > I can tell you that there are many TTYtter users, including myself as we > speak, who tweet over ssh back to their server. There may not be a browser > for them to talk to. > > There are also users who use it not as a client, but as a command line > tool for cron jobs. > > xAuth, as I understand it, is for the browserless case. > > -- > personal: > http://www.cameronkaiser.com/ -- > Cameron Kaiser * Floodgap Systems * www.floodgap.com * > ckai...@floodgap.com > -- The steady state of disks is full. -- Ken Thompson > - > > > -- > To unsubscribe, reply using "remove me" as the subject. > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
we developed xauth specifically for that - mobile and desktop clients were complaining about usability problems when they have to bounce their users to a web browser. i'm well aware of the implications about xauth, and have blogged about it here: http://mehack.com/xauth-and-perhaps-the-need-for-socializing-ap would love to hear more comments as i formalize my thoughts around this! On Wed, Apr 14, 2010 at 6:15 AM, Jaanus wrote: > Why are you Twitter guys pushing xAuth so hard? Even for new desktop > clients? Instead of recommending a proper oAuth flow with PIN or such? > I understood its main purpose is to help legacy clients with > transition, and new clients should do proper oAuth. > > One argument I have seen is that oAuth has usability problems. I would > like to see more substance around this statement beyond just > developers thinking out loud. I have implemented oAuth in @cremeapp > (ok, it uses in-app browser instead of separate, but otherwise it is > the proper PIN flow) and not a single person has complained. I see > from usage numbers that people breeze through the oAuth authentication > just fine. I was expecting worse, but it's fine. It comes down to > proper UI design and clarity of instructions. > > > J > > > On Apr 14, 1:15 am, Taylor Singletary > wrote: > > Basic auto being turned off means just that.. > > > > Desktop clients can implement xAuth as an alternative, where you do a > > one-time exchange of login and password for an OAuth access token and > > continue from there signing your requests and doing things in the > > OAuth way. You'd no longer, as a best practice and one that I would > > stress in the upmost even on a desktop client, store the login and > > password beyond the xAuth access token negotiation step. If the token > > were revoked you would then query for the login and password again and > > so on and so on and also and also. > > > > Obtaining permission to use xAuth for desktop clients is as easy as > > sending a well-identified and verbose note to a...@twitter.com. > > > > Basic auth had a good run. It's nearly time to say goodnight. > > > > Taylor > > > > > > > > > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > > Just so I understand this, applications running on the desktop will > still work correct? Basic functionality is only being turned off for web > apps correct? It's not like desktop apps will have to start using oauth. > > > > > Cheers, > > > > > Dean > > > > > -Original Message- > > > From: twitter-development-talk@googlegroups.com [mailto: > twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius > > > Sent: Tuesday, April 13, 2010 7:31 PM > > > To: Twitter Development Talk > > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > > > Could you please announce the hard turn off date somewhere on one of > > > your Twitter blogs about a month ahead of time, so that we all have an > > > official source to point our users to when we explain to them why > > > we're converting everything over to OAuth? > > > > > On Apr 13, 8:19 pm, Raffi Krikorian wrote: > > >> we have announced deprecation, and will hard turn off basic > authentication > > >> in june. the exact date has not been set, but i presume it will be > later in > > >> the month. > > > > >> Is Basic Auth going to be deprecated (as in hard switched-off) in > > > > >> > June, or are you in June going to announce depracation, with the > hard > > >> > switch-off then coming a few months later? > > > > >> -- > > >> Raffi Krikorian > > >> Twitter Platform Teamhttp://twitter.com/raffi > > > > > -- > > > To unsubscribe, reply using "remove me" as the subject. > > > > -- > > Taylor Singletary > > Developer Advocate, Twitterhttp://twitter.com/episod > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
i would love it to :P On Wed, Apr 14, 2010 at 6:18 AM, wrote: > > - "Raffi Krikorian" wrote: > > > in my ideal world, nobody would have access to a user's password > > except twitter.com -- oauth provides a framework so end applications > > are not storing the actual password. people are notoriously bad with > > using the same password on lots of different sites. additionally, > > oauth provides twitter better visibility into the traffic coming into > > our system, so we can better shape traffic needs, we can provide > > auditing back to users on which applications are doing what actions on > > their behalf, etc. > > Audit trails for users? Hear, hear!! Where is this on the roadmap? I know > people who'd love this!! > > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
again - overly dramatic. everything i said above still stands - it provides transparency into the traffic that applications generate (potentially audit trails for users, better ways to squelch spammy apps, etc.), as well as provides some security in that user's passwords are not being sent in the clear. you can easily look for other examples of people using oauth for similar situations - google is using oauth to allow applications access to mail, etc. > So basically you are saying Twitter wants a chokehold to block apps they > don’t like which you don’t currently have with basic auth. > > Considering your recent purchase of a twitter client is that really a > message you want to be spreading at the moment? > > How about leaving it up to end users to make the decision about which > clients they do and don’t use to access twitter. Restricting all clients to > oauth only is hardly going to give developers warm and fuzzy feelings that > with a single keystroke a client can be banned instantly across the entire > ecosystem. > > > > Or am I missing something? > > > > > > > > > > Cheers, > > Dean > > > -- > > *From:* twitter-development-talk@googlegroups.com [mailto: > twitter-development-t...@googlegroups.com] *On Behalf Of *Raffi Krikorian > *Sent:* Wednesday, April 14, 2010 8:59 AM > *To:* twitter-development-talk@googlegroups.com > *Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation > > > > in my ideal world, nobody would have access to a user's password except > twitter.com -- oauth provides a framework so end applications are not > storing the actual password. people are notoriously bad with using the same > password on lots of different sites. additionally, oauth provides twitter > better visibility into the traffic coming into our system, so we can better > shape traffic needs, we can provide auditing back to users on which > applications are doing what actions on their behalf, etc. > > > > On Wed, Apr 14, 2010 at 5:39 AM, Dean 'at' Cognation dot Net < > d...@cognation.net> wrote: > > But why is oauth better than basic for a desktop client? > > i understand it for the webapps but on a desktop client whats the > point? > > Basically you are saying the desktop end user cant be trusted? Sorry > but that doesn't make any sense. > > > > Please explain. > > > Cheers, > Dean > > > > On Apr 14, 1:15 am, Taylor Singletary > wrote: > > > Basic auto being turned off means just that.. > > > > Desktop clients can implement xAuth as an alternative, where you do a > > one-time exchange of login and password for an OAuth access token and > > continue from there signing your requests and doing things in the > > OAuth way. You'd no longer, as a best practice and one that I would > > stress in the upmost even on a desktop client, store the login and > > password beyond the xAuth access token negotiation step. If the token > > were revoked you would then query for the login and password again and > > so on and so on and also and also. > > > > Obtaining permission to use xAuth for desktop clients is as easy as > > > sending a well-identified and verbose note to a...@twitter.com. > > > > > Basic auth had a good run. It's nearly time to say goodnight. > > > > Taylor > > > > > > > > > > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > > Just so I understand this, applications running on the desktop will > still work correct? Basic functionality is only being turned off for web > apps correct? It's not like desktop apps will have to start using oauth. > > > > > Cheers, > > > > > Dean > > > > > -Original Message- > > > From: twitter-development-talk@googlegroups.com [mailto: > twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius > > > Sent: Tuesday, April 13, 2010 7:31 PM > > > To: Twitter Development Talk > > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > > > Could you please announce the hard turn off date somewhere on one of > > > your Twitter blogs about a month ahead of time, so that we all have an > > > official source to point our users to when we explain to them why > > > we're converting everything over to OAuth? > > > > > On Apr 13, 8:19 pm, Raffi Krikorian wrote: > > >> we have announced deprecation, and will hard turn off basic > authentication > > >> in june. the exact date has not been set, but i presume it will be > later
Re: [twitter-dev] Re: Basic Auth Deprecation
On Wed, Apr 14, 2010 at 8:39 AM, Dean 'at' Cognation dot Net wrote: > But why is oauth better than basic for a desktop client? > > i understand it for the webapps but on a desktop client whats the > point? > > Basically you are saying the desktop end user cant be trusted? Sorry > but that doesn't make any sense. > > Please explain. ARGH. Are you kidding me?! Here's a simple use case: "Change your Twitter password" If you are using only OAuth apps, they will be unaffected. If you are using Basic Auth apps, you will have to go around and update all of them OR risk being locked out of your Twitter account. I know; this just happened to me. More below… On Wed, Apr 14, 2010 at 9:28 AM, Dean Collins wrote: > > So basically you are saying Twitter wants a chokehold to block apps they > don’t like which you don’t currently have with basic auth. > > Considering your recent purchase of a twitter client is that really a > message you want to be spreading at the moment? > > How about leaving it up to end users to make the decision about which > clients they do and don’t use to access twitter. Restricting all clients to > oauth only is hardly going to give developers warm and fuzzy feelings that > with a single keystroke a client can be banned instantly across the entire > ecosystem. > > Or am I missing something? Dean, seriously, lay off the X-Files re-runs. They're making you sound paranoid. Twitter has been talking about this for ***at least*** 6 months, maybe 12. Bringing up the purchase of Tweetie only make it looks like you have an axe to grind. "Leave it to end users"? Because end users will do what developers will do: the laziest option available. Requiring users to repeatedly type Twitter passwords is going to lead most of them to a) use insecure passwords and b) not change them. Forcing developers who would otherwise be too lazy to implement OAuth to change will make it better for users and developers in the long run. I say this as someone whose ONLY method of interacting with the Twitter API is on the commandline, meaning that I am going to have to look at every single piece of code I've written, every little shell script (several dozen, at least) to see where I have to change things. And I don't make a dime from this, I'm providing a free service. As are — oh yeah — Twitter. Giving away your password is insecure. Twitter users have been extremely vulnerable to this. This will make Twitter accounts more secure. It's a good thing that requires extra work. Changing your password when using Basic Auth is a giant PITA. I know because I just did it across all my Twitter accounts and clients. And anyone who says that Twitter is "springing" this on people is either a liar or ignorant. TjL -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
Dean, Basic auth sends the password essentially in the clear (encoded, but trivially so). It's really in everybody's best interest NOT to use basic auth, but to switch to something less sniffable/repeatable. For example, here's a sample "credential" you're passing to twitter (HTTP header) when you use basic auth: *Authorization: Basic bm9ib2R5OndoYXRldmVy * Go to http://ostermiller.org/calc/encode.html, paste bm9ib2R5OndoYXRldmVy into the box and click "Decode" next to Base 64. Now you have my password. Sniff some HTTP requests and you've got a whole lot of passwords. Completely non-secure. I'm not even sure why basic auth ever gained any sort of acceptance. Switching off basic auth and onto something like OAuth, any of your users who value their privacy will thank you! 1 for deprecating basic auth. Dan On Wed, Apr 14, 2010 at 9:28 AM, Dean Collins wrote: > So basically you are saying Twitter wants a chokehold to block apps they > don’t like which you don’t currently have with basic auth. > > > > Considering your recent purchase of a twitter client is that really a > message you want to be spreading at the moment? > > > > How about leaving it up to end users to make the decision about which > clients they do and don’t use to access twitter. Restricting all clients to > oauth only is hardly going to give developers warm and fuzzy feelings that > with a single keystroke a client can be banned instantly across the entire > ecosystem. > > > > Or am I missing something? > > > > > > > > > > Cheers, > > Dean > > > -- > > *From:* twitter-development-talk@googlegroups.com [mailto: > twitter-development-t...@googlegroups.com] *On Behalf Of *Raffi Krikorian > *Sent:* Wednesday, April 14, 2010 8:59 AM > *To:* twitter-development-talk@googlegroups.com > *Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation > > > > in my ideal world, nobody would have access to a user's password except > twitter.com -- oauth provides a framework so end applications are not > storing the actual password. people are notoriously bad with using the same > password on lots of different sites. additionally, oauth provides twitter > better visibility into the traffic coming into our system, so we can better > shape traffic needs, we can provide auditing back to users on which > applications are doing what actions on their behalf, etc. > > > > On Wed, Apr 14, 2010 at 5:39 AM, Dean 'at' Cognation dot Net < > d...@cognation.net> wrote: > > But why is oauth better than basic for a desktop client? > > i understand it for the webapps but on a desktop client whats the > point? > > Basically you are saying the desktop end user cant be trusted? Sorry > but that doesn't make any sense. > > > > Please explain. > > > Cheers, > Dean > > > > On Apr 14, 1:15 am, Taylor Singletary > wrote: > > > Basic auto being turned off means just that.. > > > > Desktop clients can implement xAuth as an alternative, where you do a > > one-time exchange of login and password for an OAuth access token and > > continue from there signing your requests and doing things in the > > OAuth way. You'd no longer, as a best practice and one that I would > > stress in the upmost even on a desktop client, store the login and > > password beyond the xAuth access token negotiation step. If the token > > were revoked you would then query for the login and password again and > > so on and so on and also and also. > > > > Obtaining permission to use xAuth for desktop clients is as easy as > > > sending a well-identified and verbose note to a...@twitter.com. > > > > > Basic auth had a good run. It's nearly time to say goodnight. > > > > Taylor > > > > > > > > > > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > > Just so I understand this, applications running on the desktop will > still work correct? Basic functionality is only being turned off for web > apps correct? It's not like desktop apps will have to start using oauth. > > > > > Cheers, > > > > > Dean > > > > > -Original Message- > > > From: twitter-development-talk@googlegroups.com [mailto: > twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius > > > Sent: Tuesday, April 13, 2010 7:31 PM > > > To: Twitter Development Talk > > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > > > Could you please announce the hard turn off date somewhere on one of > > &
Re: [twitter-dev] Re: Basic Auth Deprecation
> Why are you Twitter guys pushing xAuth so hard? Even for new desktop > clients? Instead of recommending a proper oAuth flow with PIN or such? > I understood its main purpose is to help legacy clients with > transition, and new clients should do proper oAuth. I can tell you that there are many TTYtter users, including myself as we speak, who tweet over ssh back to their server. There may not be a browser for them to talk to. There are also users who use it not as a client, but as a command line tool for cron jobs. xAuth, as I understand it, is for the browserless case. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- The steady state of disks is full. -- Ken Thompson - -- To unsubscribe, reply using "remove me" as the subject.
RE: [twitter-dev] Re: Basic Auth Deprecation
So basically you are saying Twitter wants a chokehold to block apps they don't like which you don't currently have with basic auth. Considering your recent purchase of a twitter client is that really a message you want to be spreading at the moment? How about leaving it up to end users to make the decision about which clients they do and don't use to access twitter. Restricting all clients to oauth only is hardly going to give developers warm and fuzzy feelings that with a single keystroke a client can be banned instantly across the entire ecosystem. Or am I missing something? Cheers, Dean From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi Krikorian Sent: Wednesday, April 14, 2010 8:59 AM To: twitter-development-talk@googlegroups.com Subject: Re: [twitter-dev] Re: Basic Auth Deprecation in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean 'at' Cognation dot Net wrote: But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary wrote: > Basic auto being turned off means just that.. > > Desktop clients can implement xAuth as an alternative, where you do a > one-time exchange of login and password for an OAuth access token and > continue from there signing your requests and doing things in the > OAuth way. You'd no longer, as a best practice and one that I would > stress in the upmost even on a desktop client, store the login and > password beyond the xAuth access token negotiation step. If the token > were revoked you would then query for the login and password again and > so on and so on and also and also. > > Obtaining permission to use xAuth for desktop clients is as easy as > sending a well-identified and verbose note to a...@twitter.com. > > Basic auth had a good run. It's nearly time to say goodnight. > > Taylor > > > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. > > > Cheers, > > > Dean > > > -Original Message- > > From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius > > Sent: Tuesday, April 13, 2010 7:31 PM > > To: Twitter Development Talk > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > Could you please announce the hard turn off date somewhere on one of > > your Twitter blogs about a month ahead of time, so that we all have an > > official source to point our users to when we explain to them why > > we're converting everything over to OAuth? > > > On Apr 13, 8:19 pm, Raffi Krikorian wrote: > >> we have announced deprecation, and will hard turn off basic authentication > >> in june. the exact date has not been set, but i presume it will be later in > >> the month. > > >> Is Basic Auth going to be deprecated (as in hard switched-off) in > > >> > June, or are you in June going to announce depracation, with the hard > >> > switch-off then coming a few months later? > > >> -- > >> Raffi Krikorian > >> Twitter Platform Teamhttp://twitter.com/raffi > > > -- > > To unsubscribe, reply using "remove me" as the subject. > > -- > Taylor Singletary > Developer Advocate, Twitterhttp://twitter.com/episod- Hide quoted text - > > - Show quoted text - -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation
- "Raffi Krikorian" wrote: > in my ideal world, nobody would have access to a user's password > except twitter.com -- oauth provides a framework so end applications > are not storing the actual password. people are notoriously bad with > using the same password on lots of different sites. additionally, > oauth provides twitter better visibility into the traffic coming into > our system, so we can better shape traffic needs, we can provide > auditing back to users on which applications are doing what actions on > their behalf, etc. Audit trails for users? Hear, hear!! Where is this on the roadmap? I know people who'd love this!!
[twitter-dev] Re: Basic Auth Deprecation
I like oAuth because for both Twitter and me as a developer, it associates the request with both the user and app. As a developer, I have a bunch of apps and I can go to twitter.com/oauth to see the number of users that have used each app. (One thing that I noticed - the number goes down sometimes??? Why is that?) Twitter can do things like block rogue apps, analyze popularity easily etc. On Apr 14, 8:58 am, Raffi Krikorian wrote: > in my ideal world, nobody would have access to a user's password except > twitter.com -- oauth provides a framework so end applications are not > storing the actual password. people are notoriously bad with using the same > password on lots of different sites. additionally, oauth provides twitter > better visibility into the traffic coming into our system, so we can better > shape traffic needs, we can provide auditing back to users on which > applications are doing what actions on their behalf, etc. > > On Wed, Apr 14, 2010 at 5:39 AM, Dean 'at' Cognation dot Net < > > > > > > d...@cognation.net> wrote: > > But why is oauth better than basic for a desktop client? > > > i understand it for the webapps but on a desktop client whats the > > point? > > > Basically you are saying the desktop end user cant be trusted? Sorry > > but that doesn't make any sense. > > > Please explain. > > > Cheers, > > Dean > > > On Apr 14, 1:15 am, Taylor Singletary > > wrote: > > > Basic auto being turned off means just that.. > > > > Desktop clients can implement xAuth as an alternative, where you do a > > > one-time exchange of login and password for an OAuth access token and > > > continue from there signing your requests and doing things in the > > > OAuth way. You'd no longer, as a best practice and one that I would > > > stress in the upmost even on a desktop client, store the login and > > > password beyond the xAuth access token negotiation step. If the token > > > were revoked you would then query for the login and password again and > > > so on and so on and also and also. > > > > Obtaining permission to use xAuth for desktop clients is as easy as > > > sending a well-identified and verbose note to a...@twitter.com. > > > > Basic auth had a good run. It's nearly time to say goodnight. > > > > Taylor > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > > > Just so I understand this, applications running on the desktop will > > still work correct? Basic functionality is only being turned off for web > > apps correct? It's not like desktop apps will have to start using oauth. > > > > > Cheers, > > > > > Dean > > > > > -Original Message- > > > > From: twitter-development-talk@googlegroups.com [mailto: > > twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius > > > > Sent: Tuesday, April 13, 2010 7:31 PM > > > > To: Twitter Development Talk > > > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > > > Could you please announce the hard turn off date somewhere on one of > > > > your Twitter blogs about a month ahead of time, so that we all have an > > > > official source to point our users to when we explain to them why > > > > we're converting everything over to OAuth? > > > > > On Apr 13, 8:19 pm, Raffi Krikorian wrote: > > > >> we have announced deprecation, and will hard turn off basic > > authentication > > > >> in june. the exact date has not been set, but i presume it will be > > later in > > > >> the month. > > > > >> Is Basic Auth going to be deprecated (as in hard switched-off) in > > > > >> > June, or are you in June going to announce depracation, with the > > hard > > > >> > switch-off then coming a few months later? > > > > >> -- > > > >> Raffi Krikorian > > > >> Twitter Platform Teamhttp://twitter.com/raffi > > > > > -- > > > > To unsubscribe, reply using "remove me" as the subject. > > > > -- > > > Taylor Singletary > > > Developer Advocate, Twitterhttp://twitter.com/episod-Hide quoted text - > > > > - Show quoted text - > > -- > Raffi Krikorian > Twitter Platform Teamhttp://twitter.com/raffi
[twitter-dev] Re: Basic Auth Deprecation
Why are you Twitter guys pushing xAuth so hard? Even for new desktop clients? Instead of recommending a proper oAuth flow with PIN or such? I understood its main purpose is to help legacy clients with transition, and new clients should do proper oAuth. One argument I have seen is that oAuth has usability problems. I would like to see more substance around this statement beyond just developers thinking out loud. I have implemented oAuth in @cremeapp (ok, it uses in-app browser instead of separate, but otherwise it is the proper PIN flow) and not a single person has complained. I see from usage numbers that people breeze through the oAuth authentication just fine. I was expecting worse, but it's fine. It comes down to proper UI design and clarity of instructions. J On Apr 14, 1:15 am, Taylor Singletary wrote: > Basic auto being turned off means just that.. > > Desktop clients can implement xAuth as an alternative, where you do a > one-time exchange of login and password for an OAuth access token and > continue from there signing your requests and doing things in the > OAuth way. You'd no longer, as a best practice and one that I would > stress in the upmost even on a desktop client, store the login and > password beyond the xAuth access token negotiation step. If the token > were revoked you would then query for the login and password again and > so on and so on and also and also. > > Obtaining permission to use xAuth for desktop clients is as easy as > sending a well-identified and verbose note to a...@twitter.com. > > Basic auth had a good run. It's nearly time to say goodnight. > > Taylor > > > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > Just so I understand this, applications running on the desktop will still > > work correct? Basic functionality is only being turned off for web apps > > correct? It's not like desktop apps will have to start using oauth. > > > Cheers, > > > Dean > > > -Original Message- > > From: twitter-development-talk@googlegroups.com > > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald > > Pretorius > > Sent: Tuesday, April 13, 2010 7:31 PM > > To: Twitter Development Talk > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > Could you please announce the hard turn off date somewhere on one of > > your Twitter blogs about a month ahead of time, so that we all have an > > official source to point our users to when we explain to them why > > we're converting everything over to OAuth? > > > On Apr 13, 8:19 pm, Raffi Krikorian wrote: > >> we have announced deprecation, and will hard turn off basic authentication > >> in june. the exact date has not been set, but i presume it will be later > >> in > >> the month. > > >> Is Basic Auth going to be deprecated (as in hard switched-off) in > > >> > June, or are you in June going to announce depracation, with the hard > >> > switch-off then coming a few months later? > > >> -- > >> Raffi Krikorian > >> Twitter Platform Teamhttp://twitter.com/raffi > > > -- > > To unsubscribe, reply using "remove me" as the subject. > > -- > Taylor Singletary > Developer Advocate, Twitterhttp://twitter.com/episod
Re: [twitter-dev] Re: Basic Auth Deprecation
in my ideal world, nobody would have access to a user's password except twitter.com -- oauth provides a framework so end applications are not storing the actual password. people are notoriously bad with using the same password on lots of different sites. additionally, oauth provides twitter better visibility into the traffic coming into our system, so we can better shape traffic needs, we can provide auditing back to users on which applications are doing what actions on their behalf, etc. On Wed, Apr 14, 2010 at 5:39 AM, Dean 'at' Cognation dot Net < d...@cognation.net> wrote: > But why is oauth better than basic for a desktop client? > > i understand it for the webapps but on a desktop client whats the > point? > > Basically you are saying the desktop end user cant be trusted? Sorry > but that doesn't make any sense. > > > > Please explain. > > > Cheers, > Dean > > > > On Apr 14, 1:15 am, Taylor Singletary > wrote: > > Basic auto being turned off means just that.. > > > > Desktop clients can implement xAuth as an alternative, where you do a > > one-time exchange of login and password for an OAuth access token and > > continue from there signing your requests and doing things in the > > OAuth way. You'd no longer, as a best practice and one that I would > > stress in the upmost even on a desktop client, store the login and > > password beyond the xAuth access token negotiation step. If the token > > were revoked you would then query for the login and password again and > > so on and so on and also and also. > > > > Obtaining permission to use xAuth for desktop clients is as easy as > > sending a well-identified and verbose note to a...@twitter.com. > > > > Basic auth had a good run. It's nearly time to say goodnight. > > > > Taylor > > > > > > > > > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > > Just so I understand this, applications running on the desktop will > still work correct? Basic functionality is only being turned off for web > apps correct? It's not like desktop apps will have to start using oauth. > > > > > Cheers, > > > > > Dean > > > > > -Original Message- > > > From: twitter-development-talk@googlegroups.com [mailto: > twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius > > > Sent: Tuesday, April 13, 2010 7:31 PM > > > To: Twitter Development Talk > > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > > > Could you please announce the hard turn off date somewhere on one of > > > your Twitter blogs about a month ahead of time, so that we all have an > > > official source to point our users to when we explain to them why > > > we're converting everything over to OAuth? > > > > > On Apr 13, 8:19 pm, Raffi Krikorian wrote: > > >> we have announced deprecation, and will hard turn off basic > authentication > > >> in june. the exact date has not been set, but i presume it will be > later in > > >> the month. > > > > >> Is Basic Auth going to be deprecated (as in hard switched-off) in > > > > >> > June, or are you in June going to announce depracation, with the > hard > > >> > switch-off then coming a few months later? > > > > >> -- > > >> Raffi Krikorian > > >> Twitter Platform Teamhttp://twitter.com/raffi > > > > > -- > > > To unsubscribe, reply using "remove me" as the subject. > > > > -- > > Taylor Singletary > > Developer Advocate, Twitterhttp://twitter.com/episod- Hide quoted text - > > > > - Show quoted text - > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Re: Basic Auth Deprecation
But why is oauth better than basic for a desktop client? i understand it for the webapps but on a desktop client whats the point? Basically you are saying the desktop end user cant be trusted? Sorry but that doesn't make any sense. Please explain. Cheers, Dean On Apr 14, 1:15 am, Taylor Singletary wrote: > Basic auto being turned off means just that.. > > Desktop clients can implement xAuth as an alternative, where you do a > one-time exchange of login and password for an OAuth access token and > continue from there signing your requests and doing things in the > OAuth way. You'd no longer, as a best practice and one that I would > stress in the upmost even on a desktop client, store the login and > password beyond the xAuth access token negotiation step. If the token > were revoked you would then query for the login and password again and > so on and so on and also and also. > > Obtaining permission to use xAuth for desktop clients is as easy as > sending a well-identified and verbose note to a...@twitter.com. > > Basic auth had a good run. It's nearly time to say goodnight. > > Taylor > > > > > > On Tuesday, April 13, 2010, Dean Collins wrote: > > Just so I understand this, applications running on the desktop will still > > work correct? Basic functionality is only being turned off for web apps > > correct? It's not like desktop apps will have to start using oauth. > > > Cheers, > > > Dean > > > -Original Message- > > From: twitter-development-talk@googlegroups.com > > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald > > Pretorius > > Sent: Tuesday, April 13, 2010 7:31 PM > > To: Twitter Development Talk > > Subject: [twitter-dev] Re: Basic Auth Deprecation > > > Could you please announce the hard turn off date somewhere on one of > > your Twitter blogs about a month ahead of time, so that we all have an > > official source to point our users to when we explain to them why > > we're converting everything over to OAuth? > > > On Apr 13, 8:19 pm, Raffi Krikorian wrote: > >> we have announced deprecation, and will hard turn off basic authentication > >> in june. the exact date has not been set, but i presume it will be later > >> in > >> the month. > > >> Is Basic Auth going to be deprecated (as in hard switched-off) in > > >> > June, or are you in June going to announce depracation, with the hard > >> > switch-off then coming a few months later? > > >> -- > >> Raffi Krikorian > >> Twitter Platform Teamhttp://twitter.com/raffi > > > -- > > To unsubscribe, reply using "remove me" as the subject. > > -- > Taylor Singletary > Developer Advocate, Twitterhttp://twitter.com/episod- Hide quoted text - > > - Show quoted text -
Re: [twitter-dev] Re: Basic Auth Deprecation
marcel (@noradio) and i have been working on http://github.com/marcel/twurl -- there is definitely some work that needs to be done, but we're getting close. On Tue, Apr 13, 2010 at 9:01 PM, TJ Luoma wrote: > On Tue, Apr 13, 2010 at 7:35 PM, Raffi Krikorian > wrote: > > > > we'll make sure to message it long before hand! > > I'm still unclear what people who use 'curl' will do after basic auth > is deprecated. > > Is there an OAuth for the commandline? If so: pointers, please. > > TjL > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
On Tue, Apr 13, 2010 at 7:35 PM, Raffi Krikorian wrote: > > we'll make sure to message it long before hand! I'm still unclear what people who use 'curl' will do after basic auth is deprecated. Is there an OAuth for the commandline? If so: pointers, please. TjL
RE: [twitter-dev] Re: Basic Auth Deprecation
Just so I understand this, applications running on the desktop will still work correct? Basic functionality is only being turned off for web apps correct? It's not like desktop apps will have to start using oauth. Cheers, Dean -Original Message- From: twitter-development-talk@googlegroups.com [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Dewald Pretorius Sent: Tuesday, April 13, 2010 7:31 PM To: Twitter Development Talk Subject: [twitter-dev] Re: Basic Auth Deprecation Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian wrote: > we have announced deprecation, and will hard turn off basic authentication > in june. the exact date has not been set, but i presume it will be later in > the month. > > Is Basic Auth going to be deprecated (as in hard switched-off) in > > > June, or are you in June going to announce depracation, with the hard > > switch-off then coming a few months later? > > -- > Raffi Krikorian > Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using "remove me" as the subject.
Re: [twitter-dev] Re: Basic Auth Deprecation
we'll make sure to message it long before hand! On Tue, Apr 13, 2010 at 4:30 PM, Dewald Pretorius wrote: > Could you please announce the hard turn off date somewhere on one of > your Twitter blogs about a month ahead of time, so that we all have an > official source to point our users to when we explain to them why > we're converting everything over to OAuth? > > On Apr 13, 8:19 pm, Raffi Krikorian wrote: > > we have announced deprecation, and will hard turn off basic > authentication > > in june. the exact date has not been set, but i presume it will be later > in > > the month. > > > > Is Basic Auth going to be deprecated (as in hard switched-off) in > > > > > June, or are you in June going to announce depracation, with the hard > > > switch-off then coming a few months later? > > > > -- > > Raffi Krikorian > > Twitter Platform Teamhttp://twitter.com/raffi > > > -- > To unsubscribe, reply using "remove me" as the subject. > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
[twitter-dev] Re: Basic Auth Deprecation
Could you please announce the hard turn off date somewhere on one of your Twitter blogs about a month ahead of time, so that we all have an official source to point our users to when we explain to them why we're converting everything over to OAuth? On Apr 13, 8:19 pm, Raffi Krikorian wrote: > we have announced deprecation, and will hard turn off basic authentication > in june. the exact date has not been set, but i presume it will be later in > the month. > > Is Basic Auth going to be deprecated (as in hard switched-off) in > > > June, or are you in June going to announce depracation, with the hard > > switch-off then coming a few months later? > > -- > Raffi Krikorian > Twitter Platform Teamhttp://twitter.com/raffi -- To unsubscribe, reply using "remove me" as the subject.
[twitter-dev] Re: Basic Auth Deprecation in June
Another beta tester here! ;-) On Jan 18, 9:54 am, TJ Luoma wrote: > On Mon, Jan 18, 2010 at 12:48 PM, Raffi Krikorian wrote: > > we have a command line tool that acts exactly like curl but does all the > > oauth signatures transparently to the end user (the user simply needs to > > register the keys with the tool). this way people who rely on the ability > > to use curl to interact with the API (such as scripts, etc.) can still do > > so. we'll be releasing that tool soon. > > Well just about everything that I do with the API is through curl, so > let me know if you need any beta testers :-) > > Otherwise I'm just going to put everything on hold for now before I > waste any more time on stuff I'm just going to have to redo later. > > TjL
Re: [twitter-dev] Re: Basic Auth Deprecation in June
On Mon, Jan 18, 2010 at 12:48 PM, Raffi Krikorian wrote: > we have a command line tool that acts exactly like curl but does all the > oauth signatures transparently to the end user (the user simply needs to > register the keys with the tool). this way people who rely on the ability > to use curl to interact with the API (such as scripts, etc.) can still do > so. we'll be releasing that tool soon. Well just about everything that I do with the API is through curl, so let me know if you need any beta testers :-) Otherwise I'm just going to put everything on hold for now before I waste any more time on stuff I'm just going to have to redo later. TjL
Re: [twitter-dev] Re: Basic Auth Deprecation in June
we have a command line tool that acts exactly like curl but does all the oauth signatures transparently to the end user (the user simply needs to register the keys with the tool). this way people who rely on the ability to use curl to interact with the API (such as scripts, etc.) can still do so. we'll be releasing that tool soon. On Mon, Jan 18, 2010 at 9:35 AM, TJ Luoma wrote: > On Mon, Jan 18, 2010 at 11:05 AM, ryan alford > wrote: > > yes, it's official. The depreciation of Basic Auth will "start" in June. > > So — I will ask again — what are those of us using curl programs > (commandline, not web) supposed to do then? > > TwitReport works on this: > > curl --location --referer ";auto" -D - -s --netrc > > if I can't do that from the commandline, I might as well start telling > people now and stop working on the next version. > -- Raffi Krikorian Twitter Platform Team http://twitter.com/raffi
Re: [twitter-dev] Re: Basic Auth Deprecation in June
On Mon, Jan 18, 2010 at 11:05 AM, ryan alford wrote: > yes, it's official. The depreciation of Basic Auth will "start" in June. So — I will ask again — what are those of us using curl programs (commandline, not web) supposed to do then? TwitReport works on this: curl --location --referer ";auto" -D - -s --netrc if I can't do that from the commandline, I might as well start telling people now and stop working on the next version.
Re: [twitter-dev] Re: Basic Auth Deprecation in June
> Thanks. Hope it's not official. I don't remember reading anything like > that on the 2 lists. No, it wasn't posted here at the time. I insert a fairly loud *ahem* to ensure such things are posted here also in the future. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- Two can live as cheaply as one, for half as long. --
Re: [twitter-dev] Re: Basic Auth Deprecation in June
yes, it's official. The depreciation of Basic Auth will "start" in June. Ryan On Mon, Jan 18, 2010 at 10:57 AM, Hwee-Boon Yar wrote: > Thanks. Hope it's not official. I don't remember reading anything like > that on the 2 lists. > > -- > Hwee-Boon > > On Jan 18, 7:01 pm, Rich wrote: > > Ryan Sarver said it last last yearhttp:// > twitter.com/Scobleizer/status/6493268213 > > > > On Jan 17, 4:46 am, Hwee-Boon Yar wrote: > > > > > > > > > On Jan 14, 8:30 am, twittme_mobi wrote: > > > > > > Hello , > > > > > > Regarding Basic Auth Deprecation is June > > > > > Any where this is announced? > > > > > -- > > > Hwee-Boon >
[twitter-dev] Re: Basic Auth Deprecation in June
Thanks. Hope it's not official. I don't remember reading anything like that on the 2 lists. -- Hwee-Boon On Jan 18, 7:01 pm, Rich wrote: > Ryan Sarver said it last last > yearhttp://twitter.com/Scobleizer/status/6493268213 > > On Jan 17, 4:46 am, Hwee-Boon Yar wrote: > > > > > On Jan 14, 8:30 am, twittme_mobi wrote: > > > > Hello , > > > > Regarding Basic Auth Deprecation is June > > > Any where this is announced? > > > -- > > Hwee-Boon
[twitter-dev] Re: Basic Auth Deprecation in June
Ryan Sarver said it last last year http://twitter.com/Scobleizer/status/6493268213 On Jan 17, 4:46 am, Hwee-Boon Yar wrote: > On Jan 14, 8:30 am, twittme_mobi wrote: > > > Hello , > > > Regarding Basic Auth Deprecation is June > > Any where this is announced? > > -- > Hwee-Boon
[twitter-dev] Re: Basic Auth Deprecation in June
On Jan 14, 8:30 am, twittme_mobi wrote: > Hello , > > Regarding Basic Auth Deprecation is June Any where this is announced? -- Hwee-Boon
Re: [twitter-dev] Re: Basic Auth Deprecation in June
> Thanks for your reply! > Couldn't I just save the access token in a database and use it later? Yup. Many, if not most, applications do just that. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- What an incredible thing we did. -- R. J. Mical, Commodore-Amiga ---
[twitter-dev] Re: Basic Auth Deprecation in June
Hello, Thanks for your reply! Couldn't I just save the access token in a database and use it later? Thanks. On Jan 14, 1:31 am, Cameron Kaiser wrote: > > Regarding Basic Auth Deprecation is June - would it be possible using > > OAuth to automate > > some users posts - for example - there are some applications that can > > automate a post in the future. > > > Could that still work in future? > > There is going to be a browserless API, and that might serve such a > purpose. > > -- > personal:http://www.cameronkaiser.com/-- > Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com > -- FORTUNE: You have a magnetic personality. Avoid iron-based alloys. > -
[twitter-dev] Re: Basic Auth deprecation coming
Because Twitter would require keys, not usernames and passwords. Logons go to Twitter, and keys are returned. Programs would (will) break unless grandfathered, but that's a manageable issue. That said, there should be a way for developers to use Basic Auth to "hash out" (develop) their code for eventual oAuth implementations. It is too useful for developers to do initial coding (or at leasat some coding) in Basic Auth, and then tweak and package it for oAuth, as I see it. ~Patrick On Dec 9, 9:24 pm, "Dean Collins" wrote: > How are they going to stop basic auth? > > If a website already have the username/passwords doesn't that mean they > can log in on a users behalf until they change the password via the > twitter.com website? > > Cheers, > > Dean > > > > -Original Message- > From: twitter-development-talk@googlegroups.com > > [mailto:twitter-development-t...@googlegroups.com] On Behalf Of Patrick > Kennedy > Sent: Wednesday, December 09, 2009 9:12 AM > To: twitter-development-talk@googlegroups.com > Subject: [twitter-dev] Basic Auth deprecation coming > > With Basic Auth deprecation coming in June 2010, will developers have > a "sand box" way to use Basic Auth? I mean, it's handy to develop and > understand code with Basic Auth, and then cut it over to oAuth. Any > ideas?- Hide quoted text - > > - Show quoted text -
