On 8/19/2010 11:50 AM, briandunnington wrote:
as Julio stated above, the official response from Taylor (in another
thread) was that this solution will *not* be rolled out. there is
currently no other alternative being offered other.
and just to repeat what has already been said a few time in
I have an open source Twitter client for Google Chrome and this is how I
distribute it.
The source is available with no API key. If developers wish to play with the
source they must register their own OAuth application.
http://github.com/abraham/omnitweet
For users there is a packaged download
On Wed, Sep 1, 2010 at 7:58 PM, John Meyer john.l.me...@gmail.com wrote:
And that assumes that you distribute the consumerkey and consumersecret with
the app. Nothing about Open Source requires this. You could just as easily
just distribute the source and require that users obtain their own
On 9/1/2010 6:03 PM, Mike Desjardins wrote:
Yes, and your application's consumer secret ends with the following
characters: jOU
I obviously know the entire string and have the good sense not to
reveal it here. The point is, it's trivially easy for me or anybody
else to unzip your packaged
On 9/1/2010 6:46 PM, Julio Biason wrote:
On Wed, Sep 1, 2010 at 7:58 PM, John Meyerjohn.l.me...@gmail.com wrote:
And that assumes that you distribute the consumerkey and consumersecret with
the app. Nothing about Open Source requires this. You could just as easily
just distribute the source
On Wed, Sep 1, 2010 at 9:56 PM, John Meyer john.l.me...@gmail.com wrote:
And rendering the key useless to the spammer.
And to you. And your users.
That's the whole problem with it. Yes, one could simply strings(1) one
Mac app and probably retrieve the keys and spam the hell of Twitter
with it.
On Wed, Sep 1, 2010 at 9:57 PM, John Meyer john.l.me...@gmail.com wrote:
That's the way Twitter Tools for Wordpress works, and it isn't ackward at
all. It's description leaves something to be desired, but it ain't rocket
science.
WordPress users are a complete different beast than desktop
On 9/1/2010 7:01 PM, Julio Biason wrote:
That's the whole problem with it. Yes, one could simply strings(1) one
Mac app and probably retrieve the keys and spam the hell of Twitter
with it. For the spammer, it doesn't matter if the key is revoked as
he could just get another one; the real problem
On Wed, Sep 1, 2010 at 10:20 PM, John Meyer john.l.me...@gmail.com wrote:
1. reverse engineering a consumer key combo from a legit program, creating
user accounts and generating tokens, spamming it until it's locked out,
tracking down another legit program, reverse engineering it, lathering,
On 9/1/2010 7:01 PM, Julio Biason wrote:
On Wed, Sep 1, 2010 at 9:56 PM, John Meyerjohn.l.me...@gmail.com wrote:
And rendering the key useless to the spammer.
And to you. And your users.
That's the whole problem with it. Yes, one could simply strings(1) one
Mac app and probably retrieve the
On 9/1/2010 7:47 PM, Julio Biason wrote:
OAuth certainly makes sense as a model for never type your password
in some weird site 'cause you don't know when they say that they
couldn't connect to Twitter is really that or they are just storing
your login and password to abuse the ecosystem. The
On Mon, Aug 9, 2010 at 1:50 PM, Meepnix moonix...@gmail.com wrote:
Has this solution for Open Source applications using OAuth with the
Twitter API been implemented yet? As the deadline for Basic
authentication removal is looming very close; 16th August, end of this
week.
On another thread,
The answer is soon! :) We hope to roll this out more widely this week.
On Mon, Jun 28, 2010 at 7:56 AM, Decklin Foster deck...@red-bean.comwrote:
Taylor Singletary wrote:
We're waiting on a few minor bug fixes to be in place before rolling this
out to a wider audience. I'll post a new
Hi Everyone,
We're waiting on a few minor bug fixes to be in place before rolling this
out to a wider audience. I'll post a new message when things are good to go
and we're ready to accept applications into the feature.
Taylor
On Sun, Jun 20, 2010 at 1:30 AM, nov mat...@gmail.com wrote:
Hi,
In facebook's desktop authflow, rather then giving you an access_token endpoint
to call with a secret to exchange a callback and get an valid access_token, you
instead call authorize and it will redirect the user to a login_success.html
page on facebook.com with the access token in a fragment
Interesting details, and see below:
On Mon, 14 Jun 2010 10:51:34 -0700
Zac Bowling zbowl...@gmail.com wrote:
In facebook's desktop authflow, rather then giving you an
...
Basically when it comes to desktop apps, Facebook can't for sure tell
the difference between my desktop app and
If the attacker does that, the loser is only that user but not the app
(parent app) Basically this idea is to
shield the apps from being misused.
@taylor
So key exchange is done based on consumer key only.(No need to verify the
signature?.Makes sense as this is distributed )So any abuse by the
@taylor
So key exchange is done based on consumer key only.(No need to verify the
signature?.Makes sense as this is distributed )So any abuse by the end user
will only lead to the ban of child app ? (assuming the final auth requests
are signed by the generated secrets (chid app secret and
Not sure I totally like this idea. Seems almost like double authentication
to me.
The user has to still sign in via the web to replicate the app and then we
have to fetch an access token
again by asking for their credentials?? So its like doing a 3-legged dance +
the xAuth.
I really question the
Not sure I totally like this idea. Seems almost like double authentication
to me.
The user has to still sign in via the web to replicate the app and then we
have to fetch an access token
again by asking for their credentials?? So its like doing a 3-legged dance +
the xAuth.
No. The process
Sorry over looked the access token being included. I still do not think this
fits well with open source
desktop apps. I think for now just not distributing a key with the app's
source, but provide it when the app
is built (hidden in the binary or such).
On Sat, Jun 12, 2010 at 10:09 AM, Cameron
Sorry over looked the access token being included. I still do not think this
fits well with open source
desktop apps. I think for now just not distributing a key with the app's
source, but provide it when the app
is built (hidden in the binary or such).
That works fine with binaries, but may
Yes, that is a problem with any app that you distribute that has any embedded
keys. Unfortunately, you ultimately can't really entirely secure anything you
ship that a user can run on their own machine. You can however take a few steps
to make that extremely difficult by encrypting and
Yes, this is correct. To perform this key exchange, a consumer key (API key)
with this feature enabled is all that's required to be stored in your open
source app.
Some other interesting facts:
- A parent application can only spawn 1 version of itself for a user. If
the user repeats the flow,
On Sat, 12 Jun 2010 09:48:15 -0700
Zac Bowling zbowl...@gmail.com wrote:
Yes, that is a problem with any app that you distribute that has any
embedded keys. Unfortunately, you ultimately can't really entirely
secure anything you ship that a user can run on their own machine.
You can however
I think you're missing the point, Taylor. It's not a matter of
validation, but actually being able to copy such a long string. I have
trouble with this on mobile, and I think I'm a pretty savvy user. I
*guarantee* you the rate of failure, and giving up on the process
entirely, will be much
On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
Application authors are being asked to devote substantial resources to
the OAuth conversion, but OAuth provides no security for application
authors!
It does from a web app perspective which is the primary design goal of OAuth
since there
Yeah, it's really the step of manually getting that long string of
seemingly-random characters from one app to another. a callback url
makes sense for web-based apps.
Something like PIN auth that would allow a desktop/mobile app to make
an HTTP call and recover the string programatically
On Sat, 12 Jun 2010 13:25:44 -0700
Zac Bowling zbowl...@gmail.com wrote:
On Jun 12, 2010, at 11:57 AM, Jef Poskanzer wrote:
Application authors are being asked to devote substantial resources
to the OAuth conversion, but OAuth provides no security for
application authors!
It does from a
On Jun 12, 2010, at 3:05 PM, Bernd Stramm wrote:
I've been pondering how you could solve this from my experience with
solving these issues with SSL/TLS. One idea is having a sort of
delegation chain where I could generate a new delegated secret for
each copy of my app I distribute rather then
Quoting funkatron funkat...@gmail.com:
Yeah, it's really the step of manually getting that long string of
seemingly-random characters from one app to another. a callback url
makes sense for web-based apps.
Something like PIN auth that would allow a desktop/mobile app to make
an HTTP call and
Right, and...
On Sat, 12 Jun 2010 16:09:47 -0700 (PDT)
Jef Poskanzer jef.poskan...@gmail.com wrote:
You know, it's right there in the OAuth RFC.
http://tools.ietf.org/html/rfc5849#section-4.6
4.6. Secrecy of the Client Credentials
In many cases, the client application will be under
32 matches
Mail list logo
