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
