Hi Shannon,

There are some concerns about localhost redirection but in the mean time I recommend changing your /etc/hosts (or equivalent) so you can intercept calls on your local machine. This should also let you do development once your project launches.

Thanks;
  – Matt Sanford / @mzsanford
      Twitter API Developer



On Apr 24, 2009, at 07:47 AM, Shannon Whitley wrote:


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 <m...@twitter.com> 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 <lollic...@gmail.com> 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 <d...@twitter.com> 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
<billrobertso...@gmail.com>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 <a...@twitter.com> 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 <bwan...@gmail.com> 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 <a...@twitter.com> 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 -

Reply via email to