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 > > > > >>>>> -- > > > >>>>> Alex Payne - API Lead, Twitter, Inc.http://twitter.com/al3x-Hide > > > >>>>> quoted text - > > > > >>> - Show quoted text -
