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 - >
