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
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 /
Thanks. That's exactly what I did. ;)
On Apr 24, 7:56 am, Matt Sanford m...@twitter.com wrote:
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
This is a nifty idea, I assume it's going to break when the user has
to do something other than click Allow right? e.g. login...
On Apr 24, 10:47 am, Shannon Whitley shannon.whit...@gmail.com
wrote:
Thanks for all your hard work, Matt.
In one of my solutions, I am getting around the absence
Our OAuth-based sign-in and API-using service is up:
https://tools.povo.com/Profile/Signin/
Noticed another thing - Twitter isn't sending screen_name on the
redirect anymore.
On Apr 24, 1:33 pm, djMax djm...@gmail.com wrote:
This is a nifty idea, I assume it's going to break when the user has
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...
Here is the official OAuth statement: http://oauth.net/advisories/2009-1
On Thu, Apr 23, 2009 at 03:44, 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
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
That is, in fact, what Beta typically means: not suitable for
production use. Overuse of the term by a few popular web apps
notwithstanding.
--
Ed Finkler
http://funkatron.com
Twitter:@funkatron
AIM: funka7ron
ICQ: 3922133
XMPP:funkat...@gmail.com
On Apr 23, 9:25 am, mikehar m...@picnik.com
Corrected: Overuse of the term by almost every web app since 2002,
including GMail, notwithstanding.
On Thu, Apr 23, 2009 at 10:01 AM, Ed Finkler funkat...@gmail.com wrote:
That is, in fact, what Beta typically means: not suitable for
production use. Overuse of the term by a few popular web
What does this really mean these days? Clearly your desktop app is
connected to the internet in some way at some point, otherwise you
wouldn't need Twitter. So are you just saying that you never want to
have to display an HTML page? What about a web based activation
stage that yielded some
Corrected: Overuse of the term by almost every web app since 2002,
including GMail, notwithstanding.
s/GMail/*.google.com/
--
personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com
-- The
haha, agreed.
On Thu, Apr 23, 2009 at 10:43 AM, Cameron Kaiser spec...@floodgap.comwrote:
Corrected: Overuse of the term by almost every web app since 2002,
including GMail, notwithstanding.
s/GMail/*.google.com/
--
personal:
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.
On 4/23/09 4:44 AM, twitscoop wrote:
Anyways, even with this security flow, oauth is safer than providing
twitter credentials to third parties...
This is _absolutely_ NOT true! An attacker can't get in the middle of
an application communicating to Twitter using HTTP Basic Auth. but they
On 4/23/09 11:21 AM, Dossy Shiobara wrote:
On 4/23/09 10:04 AM, Andrew Badera wrote:
Corrected: Overuse of the term by almost every web app since 2002,
including GMail, notwithstanding.
Web 2.0: It's Beta.
(Forgive the pun, it's still early in the day ...)
--
Dossy Shiobara
On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobara do...@panoptic.com wrote:
An attacker can't get in the middle of an
application communicating to Twitter using HTTP Basic Auth.
WRONG. Anyone doing any sort of packet sniffing could easily get
user/pass combos at will. Wireless promiscuous
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 m...@twitter.com wrote:
Hi all,
We had to wait for the midnight deadline before giving too many
details
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
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
What, could you hear me groaning from all the way up in Albany? ;)
On Thu, Apr 23, 2009 at 11:24 AM, Dossy Shiobara do...@panoptic.com wrote:
On 4/23/09 11:21 AM, Dossy Shiobara wrote:
On 4/23/09 10:04 AM, Andrew Badera wrote:
Corrected: Overuse of the term by almost every web app since
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%
Thanks, Matt! Even though it kills my latest project, I'm still in
agreement that turning oAuth back on without oauth_callback is
preferable to leaving it off.
oauth_callback is very important to me, though, so I would lobby for
bringing it back in some form as quickly as possible.
Apr 23,
Glad you stepped in, Chad, because I felt really stupid for a second.
And like I said, it's less harmful to have your oAuth session stolen
(you can just unauthorize the application) than to have your plain
twitter credentials exposed.
Anyway this is not the subject of this thread, I'm just glad
I understand killing oauth_callback, but I would propose that you
shouldn't kill the ability for the app to send info that will be
returned to it upon redirecting. Is this possible? For example, you
could simply pass oauth_callback back to the calling app even though
you're not going to listen
On 4/23/09 11:33 AM, Chad Etzel wrote:
On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobarado...@panoptic.com wrote:
An attacker can't get in the middle of an
application communicating to Twitter using HTTP Basic Auth.
WRONG. Anyone doing any sort of packet sniffing could easily get
user/pass
On Thu, Apr 23, 2009 at 2:35 PM, Dossy Shiobara do...@panoptic.com wrote:
On 4/23/09 11:33 AM, Chad Etzel wrote:
On Thu, Apr 23, 2009 at 11:19 AM, Dossy Shiobarado...@panoptic.com
wrote:
An attacker can't get in the middle of an
application communicating to Twitter using HTTP Basic Auth.
@mzsanford
Thanks Matt, no matter what all these other Yahoo's are saying about
you, it's appreciated!
(j/k to all you Yahoo's) ;^)
-Michael
p.s. Is OAuth back on yet? I'd hate to see it start getting the
nickname of NOAuth.
On Apr 23, 1:43 pm, Chad Etzel jazzyc...@gmail.com wrote:
On Thu,
Mobasoft,
Rest assured we will make an announcement when OAuth support is restored.
Doug Williams
Twitter API Support
http://twitter.com/dougw
On Thu, Apr 23, 2009 at 12:42 PM, Mobasoft mobat...@gmail.com wrote:
@mzsanford
Thanks Matt, no matter what all these other Yahoo's are saying
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
On Fri, Apr 24, 2009 at 12:14 AM, djMax djm...@gmail.com wrote:
What does this really mean these days? Clearly your desktop app is
connected to the internet in some way at some point,
Well, my *console*, *non-graphical* application is connected to the
internet, yes. Also, if that makes it
On 4/22/09 4:27 PM, Alex Payne wrote:
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
My understanding is, at present, that OAuth consumers are not impacted
by this issue.
On Wed, Apr 22, 2009 at 13:29, Dossy Shiobara do...@panoptic.com wrote:
On 4/22/09 4:27 PM, Alex Payne wrote:
In cooperation with this consortium of other OAuth providers
(including Yahoo!, Google,
On 4/22/09 4:37 PM, Alex Payne wrote:
My understanding is, at present, that OAuth consumers are not impacted
by this issue.
Perfect, thanks.
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
He realized the fastest
Everyone is using terms like mitigate rather then fix, which a
clue there is probably a flaw in design that isn't accounting for the
social engineering aspect.
Maybe something that could confuse users to give their user
credentials to a third party and not the real OAuth provider when they
think
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:
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
I'm going to have to side with Alex on this one. The APIs should be
protected by OAuth and that is what should be pushed out and the basic
auth deprecated. What I don't really understand is why it has taken
until now to promote OAuth. I understand OAuth is an evolving
standard, but it has
On 4/22/09 8:23 PM, Chris Latko wrote:
I'm going to have to side with Alex on this one. The APIs should be
protected by OAuth and that is what should be pushed out and the basic
auth deprecated. What I don't really understand is why it has taken
until now to promote OAuth. I understand OAuth is
On Thu, Apr 23, 2009 at 10:23 AM, Chris Latko ch...@latko.org wrote:
I'm going to have to side with Alex on this one. The APIs should be
protected by OAuth and that is what should be pushed out and the basic
auth deprecated. What I don't really understand is why it has taken
until now to
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
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
42 matches
Mail list logo
