Thanks, Matt! Even though it kills my latest project, I'm still in agreement that turning oAuth back on without oauth_callback is preferable to leaving it off.
oauth_callback is very important to me, though, so I would lobby for bringing it back in some form as quickly as possible. Apr 23, 9:37 am, Matt Sanford <[email protected]> wrote: > Hi there, > > It isn't slowing anything. My first change was just to disable > oauth_callback, this other method is considered gravy. I'm in total > agreement (as the OAuth implementer at Twitter) that it beats the hell > out of 0% available. I'm pushing with all my might to get this > deployed despite anyone else's priorities. I take this all far too > seriously. > > Thanks; > – Matt Sanford / @mzsanford > Twitter API Developer > > On Apr 23, 2009, at 09:32 AM, Mobasoft wrote: > > > > > Please don't let this slow down Twitter's turning it back on. > > Just let everyone set it in the application and be done with it. > > > If they want a different callback url, then simply create a MyApp_Test > > app and put in a different application return url. > > > 100% working sure in the hell beats 0% implemented while we try to > > make it dynamic for a small percentage of applications/people. > > > Thanks for taking my $0.02 > > > On Apr 23, 10:57 am, Matt Sanford <[email protected]> wrote: > >> Hi Michael, > > >> We've been discussing that in the group of people dealing with > >> the security issue. It seems like AuthSub tried that route and found > >> it to be very problematic. More often than not people went with open > >> redirectors to make it easy, and therefor bypassed all security. > >> We're > >> working on a way to allow it to be dynamic, but make sure it is > >> signed > >> so we don't have to keep it this way. This involves sending it when > >> you get the request token, and then making sure you know what you > >> sent > >> when you get the access token. Once we have a working version in the > >> wild for people to try I'll give a more detailed description. > > >> Thanks; > >> – Matt Sanford / @mzsanford > >> Twitter API Developer > > >> On Apr 23, 2009, at 08:47 AM, Michael Ivey wrote: > > >>> It would be nice to be able to set multiple allowed callbacks, if > >>> this is the case, and specify which one to use in the request. I use > >>> the callback on my dev environment so I don't have to maintain two > >>> applications. (Also, the URL verification on callbacks doesn't > >>> support port numbers, but that's a secondary issue) > > >>> -- ivey > > >>> On Thu, Apr 23, 2009 at 10:37 AM, Mobasoft <[email protected]> > >>> wrote: > > >>> Good news, the oauth_callback parameter should /always/ be set in > >>> the > >>> application imho. > >>> Looking forward to your "flip the switch" celebrations today. > > >>> On Apr 23, 9:59 am, Matt Sanford <[email protected]> wrote: > >>>> Hi all, > > >>>> We had to wait for the midnight deadline before giving too > >>>> many > >>>> details because we're taking a slightly more active approach. The > >>> code > >>>> for these changes was scheduled to go out yesterday but there was a > >>>> problem with some unrelated changes and the whole thing was rolled > >>>> back. I'm hoping to get it out early today as an emergency deploy. > >>> If > >>>> anyone has missed it, Eran posted a good explanation [1] for people > >>>> not digging the security advisory wording. > >>>> While I'm still working to get the changes out here is what > >>>> you > >>>> can expect: > > >>>> 1. The lifetime of a Request Token is now much, much shorter. This > >>> new > >>>> time limit should be long enough for a person to complete the flow, > >>>> but short enough that it cuts off attacks. > >>>> » Note this is for request tokens, not access tokens. > > >>>> 2. For the time being the oauth_callback parameter will be disabled > >>>> for both authentication and authorization. The user will be sent to > >>>> the application callback in both cases. > >>>> » I'm working with the other OAuth implementers on a way to > >>> bring > >>>> it back, and Eran mentions it a bit at the end of his post [1]. We > >>>> want to make sure it works correctly before launching it so you > >>> don't > >>>> end up spending time to implement something we then have to turn > >>> off. > > >>>> As for questions about the severity of Twitter's initial > >>> response > >>>> I think you'll find Yahoo! [2] has done the same. From the OAuth > >>>> response mails I can assure you there were others as well but since > >>>> they have no public mention of it I'll let them go unmolested. It > >>>> wasn't just Twitter, that was just the only place you were > >>> looking :) > > >>>> Thanks; > >>>> — Matt Sanford, "of Alex and Doug fame" > > >>>> [1] > >>>> -http://www.hueniverse.com/hueniverse/2009/04/explaining-the-oauth-ses > >>> ... > >>>> [2] -http://developer.yahoo.net/blog/archives/2009/04/oauth_update.html > > >>>> On Apr 23, 2009, at 06:25 AM, mikehar wrote: > > >>>>> Totally agree with Pierre. I think we all understand the security > >>>>> issue. Why was twitter's approach so much more severe than other > >>>>> services? Why not just a warning on login? Can Doug or Alex shed > >>> some > >>>>> light on this? > > >>>>> wrt the ETA, can we get an update? One blog post said yesterday, > >>> the > >>>>> posting on this site says today. > > >>>>> Also, I'm a little taken aback by the "it's beta" > >>> rationalization for > >>>>> the massive disruption in service. It's one thing to mark it as > >>> public > >>>>> beta, it's another thing entirely to define 'beta' belatedly as > >>> "not > >>>>> suitable for production use". Does that mean we get an SLA on > >>> the non- > >>>>> beta APIs? > > >>>>> On Apr 23, 1:44 am, twitscoop <[email protected]> wrote: > >>>>>> Hi guys, is there an ETA for it to be restored ? It seems Oauth's > >>>>>> recommended approach is to simply add a warning notice on > >>>>>> authorization until this is fixed (this is what Google did). > >>> Anyways, > >>>>>> even with this security flow, oauth is safer than providing > >>> twitter > >>>>>> credentials to third parties... > > >>>>>> Thanks! > >>>>>> Pierre > > >>>>>> On Apr 23, 7:30 am, Doug Williams <[email protected]> wrote: > > >>>>>>> Bill, > >>>>>>> The majority of our developers find OAuth sufficient because > >>> they > >>>>>>> are > >>>>>>> writing a Web applications. We are pleased that the > >>> deprecation of > >>>>>>> the > >>>>>>> source parameter lowered our support load and continues to drive > >>>>>>> adoption of > >>>>>>> our preferred authentication scheme. > > >>>>>>> There are of course other cases where developers find the > >>> current > >>>>>>> implementation's beta status or browser requirement > >>> concerning. I > >>>>>>> have yet > >>>>>>> to reject a source parameter request that provides a valid > >>> argument > >>>>>>> explaining why OAuth does not meet the application's needs. > > >>>>>>> Thanks, > >>>>>>> Doug Williams > >>>>>>> Twitter API Supporthttp://twitter.com/dougw > > >>>>>>> On Wed, Apr 22, 2009 at 6:50 PM, Bill Robertson > >>>>>>> <[email protected]>wrote: > > >>>>>>>> I respectfully disagree. (I would colorfully disagree, but you > >>>>>>>> seem > >>>>>>>> pretty beat up right now and you don't deserve any guff) I > >>> think > >>>>>>>> developers of smaller apps see that little tag-line as a good > >>>>>>>> source > >>>>>>>> of advertising, and it seems inaccessible now if you're new > >>> (right? > >>>>>>>> wrong?). You can only get it if you use OAuth, but OAuth is > >>> now > >>>>>>>> disabled? > > >>>>>>>> Anyway, just my $0.02. Prioritize it like everything else you > >>>>>>>> need to > >>>>>>>> do (i.e. it's the 37th #1 thing on your list.) > > >>>>>>>> Good luck. > > >>>>>>>> On Apr 22, 7:58 pm, Alex Payne <[email protected]> wrote: > >>>>>>>>> We don't consider source registration a "key feature". It's an > >>>>>>>>> incentive we provide to our developers. We wanted to > >>> encourage new > >>>>>>>>> developers to look into OAuth. It won't be in beta forever, > >>>>>>>>> after all. > > >>>>>>>>> We have to balance the reality of testing a new technology > >>> in our > >>>>>>>>> stack with encouraging that technology's adoption. OAuth will > >>>>>>>>> provide > >>>>>>>>> the Twitter developer community with a number of benefits, and > >>>>>>>>> that's > >>>>>>>>> the direction in which we want to move, even while there are > >>>>>>>>> kinks to > >>>>>>>>> work out. > > >>>>>>>>> On Wed, Apr 22, 2009 at 15:37, bwannon <[email protected]> > >>> wrote: > > >>>>>>>>>> If beta for you guys means "still in testing, not suitable > >>> for > >>>>>>>>>> production use", then why depreciate key features from basic > >>>>>>>>>> auth like > >>>>>>>>>> source registration before you have a production ready > >>> release? > > >>>>>>>>>> On Apr 22, 3:27 pm, Alex Payne <[email protected]> wrote: > >>>>>>>>>>>http://blog.twitter.com/2009/04/whats-deal-with-oauth.html > > >>>>>>>>>>> In short: there's a security issue with OAuth, and the major > >>>>>>>>>>> OAuth > >>>>>>>>>>> providers are working together to patch the vulnerability > >>> before > >>>>>>>>>>> information about the issue is publicly released. That > >>>>>>>>>>> information > >>>>>>>>>>> will be available athttp://oauth.net/atmidnight, PST. > > >>>>>>>>>>> In cooperation with this consortium of other OAuth providers > >>>>>>>>>>> (including Yahoo!, Google, Netflix, etc.), we agreed not to > >>>>>>>>>>> disclose > >>>>>>>>>>> the nature of the vulnerability, nor even that a > >>> vulnerability > >>>>>>>>>>> existed, until all members of the group agreed to do so. I > >>>>>>>>>>> apologize > >>>>>>>>>>> for what must have seemed unnecessarily tight-lipped > >>>>>>>>>>> communication > >>>>>>>>>>> around this issue, but please understand that we and the > >>> other > >>>>>>>>>>> companies involved are trying to mitigate the impact of this > >>>>>>>>>>> vulnerability as much as possible. > > >>>>>>>>>>> Please also note that our OAuth support is in beta, albeit > >>>>>>>>>>> public > >>>>>>>>>>> beta. We have not suggested to developers that they rely > >>>>>>>>>>> solely on > >>>>>>>>>>> OAuth until our support of the standard leaves beta. I know > >>>>>>>>>>> that some > >>>>>>>>>>> companies practice a policy of "perpetual beta", but at > >>>>>>>>>>> Twitter, we do > >>>>>>>>>>> not. For us, "beta" really means "still in testing, not > >>>>>>>>>>> suitable for > >>>>>>>>>>> production use". > > >>>>>>>>>>> Thanks for your patience and understanding. > > >>>>>>>>>>> -- > >>>>>>>>>>> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x > > >>>>>>>>> -- > > ... > > read more »
