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 -
