Guys, We all know that base-auth is a gold for our app and when we think about another way like OAuth we get mad.... BUT If the Toke had infinit life time (probabily will do), so the big poblem transform in a little problem with 3 steps:
1-Your Webapp redirect the user to Twitter Web Site (Authentication) 2- User put username and password 3- Twitter redirect again the user for your Webapp authenticated. For non-web app it a little different but easy any way... It's not a big deal... The most important point is the life time of token... bring OAuth and let's made this happen !!! On Thu, Feb 5, 2009 at 2:48 PM, Stuart <stut...@gmail.com> wrote: > > 2009/2/5 jstrellner <jstrell...@urltrends.com>: > > I was just thinking this, and then I read your post. It would be good > > to see a "trusted apps" section somewhere on your site, and those > > application could use Basic Auth. If they don't want to go through > > the process of being a trusted app, then they can use OAuth. > > > > Just something to think about. Could earn twitter some $$$ too. > > Could also land them in a world of pain. I wouldn't want Twitter to > endorse any product that wasn't theirs, and I doubt they would want to > either. Too risky. > > -Stuart > > > On Feb 4, 8:57 pm, Alex Payne <a...@twitter.com> wrote: > >> Thanks for the feedback, guys. We'll consider extending Basic Auth's > >> life, or maybe granting a "stay of execution" to known-good apps. At the > >> very least, we'll try not to pull the rug out from under anyone. > >> > >> > >> > >> funkatron wrote: > >> > Agreed. I do believe that the use of HTTP Basic Auth was key to the > >> > quick growth of the 3rd-party app community of Twitter, as the auth > >> > scheme is so well-understood and supported. This may or may not be as > >> > important at this point business-wise, as I suspect the Twitter > >> > userbase is large enough to overcome a fair bit of lazy user intertia. > >> > I wonder if we will see a lot less interesting API hacking (the good > >> > kind), though, and I think that would be a shame. > >> > >> > While OAuth makes a ton of sense for website-based apps, it's kind of > >> > another kettle of fish for locally-hosted apps (desktop and mobile). > >> > Moving to OAuth-only is problematic for us for these reasons: > >> > >> > 1. it complicates (and confuses) the process for users: instead of > >> > entering a username and password -- a well-understood, common process > >> > -- now the app has to push the user to a web site which hopefully > >> > explains what's going on decently. This works okay for web dorks like > >> > us, but I guarantee your avg user is going to find this confusing. > >> > Maybe not as confusing as OpenID, though. > >> > >> > 2. updating locally-hosted apps to use a new authentication system is > >> > an issue of getting thousands (or higher orders) of users to upgrade. > >> > 6 months may not be enough, even for currently active applications. > >> > Stuff in development *cough*like mine*cough* now could find themselves > >> > having to toss out a ton of code they're knee-deep in right now. > >> > Yucky. > >> > >> > My preference would be to *not* see HTTP Basic Auth go away in the > >> > foreseeable future. If that's not reasonable or possible, the 6-month > >> > window (even given that the "countdown" may not start for a few > >> > months) is pretty tight for comfort, and extending it would be much > >> > preferred. > >> > >> > Note: One might wonder why I only mention these issues in the context > >> > of local apps rather than web apps. I think the expectations and user > >> > behavior tendencies are fairly different in the desktop and mobile app > >> > space, and there are a number of ways malware is detected and > >> > contained in this area. The web app space is a lot more open and easy > >> > to exploit, and likely will be unless the whole paradigm changes. > >> > >> > -- > >> > Ed Finkler > >> >http://funkatron.com > >> > AIM: funka7ron > >> > ICQ: 3922133 > >> > Skype: funka7ron > >> > >> > On Feb 4, 10:03 pm, Cameron Kaiser<spec...@floodgap.com> wrote: > >> > >> >> I'm still (softly) repeating the hope that this will be extended, > even if > >> >> the Basic Auth API remains deprecated and static. An OAuth workflow > is > >> >> constrained for desktop apps, and for apps that aren't or can't use a > web > >> >> browser (in my case, text-mode twitter clients; other cases include > all those > >> >> little curl scripts posting monitoring information, task status, > etc.), OAuth > >> >> won't work at all. > >> > >> >> I fully support OAuth, but where appropriate. I think Ed Finkler said > it > >> >> best when he said the breadth of Twitter applications currently > extant > >> >> wouldn't exist were it not for a low barrier to entry. OAuth makes > sense > >> >> in many places, but it doesn't make sense everywhere, and I hope > alternate > >> >> methods of authentication remain possible even if they are > intentionally > >> >> limited to steer preferred traffic to an OAuth workflow. Otherwise I > suspect > >> >> the ecosystem "outside the browser" will be greatly reduced. > >> > >> >> -- > >> >> ------------------------------------ personal: > http://www.cameronkaiser.com/-- > >> >> Cameron Kaiser * Floodgap Systems *www.floodgap.com* > ckai...@floodgap.com > >> >> -- Critics are the unpaid guardians of my soul. -- E. Stanley Jones > ----------- > >> > >> -- > >> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x > > -- > http://stut.net/ > -- ---------------------------------- Analista Desenvolvedor www.espacodj.com
