Thanks for all your hard work, Matt. In one of my solutions, I am getting around the absence of the oauth_callback by using the referrer. I know referrer is unreliable, but I'm going with it for now. When the call comes back from the authorize page, the referrer still contains the information that I sent in the oauth_callback.
Additionally, if we need to setup dummy applications for testing, I'd like to request that localhost and ports be allowed on the registration page in the callback field. On Apr 23, 1:41 pm, Matt Sanford <[email protected]> wrote: > Hi Everybody! (Dr. Nick voice) > > OAuth is once again live, and as described below the > oauth_callback has been disabled. I've begun testing the replacement > options for oauth_callback and will hopefully get something out soon > to replace it. In the mean time successful authorization or > authentication will send the user to your pre-registered callback URL. > > Thanks; > – Matt Sanford / @mzsanford > Twitter API Developer > > On Apr 23, 2009, at 07:59 AM, Matt Sanford 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 > > >>>>>> -- > >>>>>> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x- > >>>>>> Hide quoted text - > > >>>> - Show quoted text -- Hide quoted text - > > - Show quoted text -
