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 mcfn...@gmail.com 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. ;)
[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 lilp...@gmail.com wrote: On Tue, Apr 13, 2010 at 11:01 PM, TJ Luoma luo...@gmail.com 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: [twitter-dev] Re: Basic Auth Deprecation
On Sat, Apr 17, 2010 at 8:09 AM, sdesapio sdesa...@gmail.com 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
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 lilp...@gmail.com wrote: On Sat, Apr 17, 2010 at 8:09 AM, sdesapio sdesa...@gmail.com 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
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 luo...@gmail.com wrote: On Tue, Apr 13, 2010 at 7:35 PM, Raffi Krikorian ra...@twitter.com 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.
[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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com 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
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 #39;at#39; 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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com 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
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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com 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
[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 ra...@twitter.com 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 #39;at#39; 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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com 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
Re: [twitter-dev] Re: Basic Auth Deprecation
- Raffi Krikorian ra...@twitter.com 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!!
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 #39;at#39; 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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com 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
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
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 d...@cognation.net 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 #39;at#39; 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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com 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
Re: [twitter-dev] Re: Basic Auth Deprecation
On Wed, Apr 14, 2010 at 8:39 AM, Dean #39;at#39; 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. 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 d...@cognation.net 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
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 #39;at#39; 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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com 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 -- 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, zn...@comcast.net wrote: - Raffi Krikorian ra...@twitter.com 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
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 jaa...@gmail.com 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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com 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
xauth is definitely useful for the browserless case. On Wed, Apr 14, 2010 at 6:33 AM, Cameron Kaiser spec...@floodgap.comwrote: 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
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 #39;at#39; 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 taylorsinglet...@twitter.com 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 d...@cognation.net 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
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 jaa...@gmail.com 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 taylorsinglet...@twitter.com 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 d...@cognation.net 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 ra...@twitter.com wrote: we have announced deprecation, and will hard turn off basic authentication in june. the exact date has not been set, but i
Re: [twitter-dev] Re: Basic Auth Deprecation
Response inline. On Wed, Apr 14, 2010 at 7:07 AM, Raffi Krikorian ra...@twitter.com 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 #39;at#39; 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 taylorsinglet...@twitter.com 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 d...@cognation.net wrote: Just so I understand this, applications running on the desktop will still work correct
[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
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 spec...@floodgap.comwrote: 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
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 lilp...@gmail.com wrote: On Tue, Apr 13, 2010 at 11:01 PM, TJ Luoma luo...@gmail.com 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
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
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 jroessl...@gmail.comwrote: 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
preserving consumer key secrecy (was: Re: [twitter-dev] Re: Basic Auth Deprecation)
On Wed, Apr 14, 2010 at 18:26, Raffi Krikorian ra...@twitter.com 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: 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.
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 geneh...@gmail.com wrote: On Wed, Apr 14, 2010 at 18:26, Raffi Krikorian ra...@twitter.com 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.
[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 ra...@twitter.com 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 dpr...@gmail.com 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 ra...@twitter.com 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
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 ra...@twitter.com 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
On Tue, Apr 13, 2010 at 7:35 PM, Raffi Krikorian ra...@twitter.com 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
[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 hweeb...@gmail.com wrote: On Jan 14, 8:30 am, twittme_mobi nlupa...@googlemail.com 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 rhyl...@gmail.com wrote: Ryan Sarver said it last last yearhttp://twitter.com/Scobleizer/status/6493268213 On Jan 17, 4:46 am, Hwee-Boon Yar hweeb...@gmail.com wrote: On Jan 14, 8:30 am, twittme_mobi nlupa...@googlemail.com wrote: Hello , Regarding Basic Auth Deprecation is June Any where this is announced? -- Hwee-Boon
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 hweeb...@gmail.com 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 rhyl...@gmail.com wrote: Ryan Sarver said it last last yearhttp:// twitter.com/Scobleizer/status/6493268213 On Jan 17, 4:46 am, Hwee-Boon Yar hweeb...@gmail.com wrote: On Jan 14, 8:30 am, twittme_mobi nlupa...@googlemail.com 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. 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
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 luo...@luomat.net wrote: On Mon, Jan 18, 2010 at 11:05 AM, ryan alford ryanalford...@gmail.com 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 12:48 PM, Raffi Krikorian ra...@twitter.com 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
[twitter-dev] Re: Basic Auth Deprecation in June
Another beta tester here! ;-) On Jan 18, 9:54 am, TJ Luoma luo...@luomat.net wrote: On Mon, Jan 18, 2010 at 12:48 PM, Raffi Krikorian ra...@twitter.com 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
[twitter-dev] Re: Basic Auth Deprecation in June
On Jan 14, 8:30 am, twittme_mobi nlupa...@googlemail.com wrote: Hello , Regarding Basic Auth Deprecation is June Any where this is announced? -- Hwee-Boon
[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 spec...@floodgap.com 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. -
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 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 d...@cognation.net 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 -
