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
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 download and get your secret. You didn't
need to
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
Is there any news on this? The deadline is now passed and I'm looking
to implement OAuth immediately in an open-source web app with exactly
this use-case. Having this feature would be very useful. Thanks.
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 this
thread - this is not just a problem with open
Strange that this was stated to be ready weeks ago and now we hear
nothing about the progress. Any one that is actually involved in
testing this able to weigh in and provide an update?
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 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,
Sounds kind of like GData workflow, is that what you are going for?
Source application installation must connect to registered API
application though an application authentication URL.
API application author has full control over expiring any application
tokens at any given point causing all
I think this solution works for my open-source C++ app. Here is my
initial thought/plan for it, let me know if I'm way off base.
1. My app complies down to native code, which is hackable but
obfuscated enough assuming I don't add my consumer secret as a string
resource into the binary :/
2.
Any further news on this? It's been three weeks since you were
hoping to roll [it] out more widely this week. I've got an app
registered and am starting to code it up, but would like to use the
key_exchange method instead, since there's no way at all to hide the
consumer secret in a python
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 message when things are good to go
and we're ready to accept applications into the feature.
Any update or ETA on this? I have an app that I'm eager to
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,
Hi, Twitter API team
Is this feature already released?
If so, how can we register key_exchange enabled consumers?
On 6月12日, 午前7:56, Taylor Singletary taylorsinglet...@twitter.com
wrote:
Hi Developers,
As has been discussed on the list recently, OAuth and Open Source
applications are a
Yeah, what Ryan said.
Also,
On Jun 13, 1:40 pm, segphault ryankp...@gmail.com wrote:
Facebook and Google Buzz both offer desktop-appropriate OAuth
authentication flows which do not require a consumer secret key and do
not require the user to go through a complicated copy/paste process.
I'm
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
Perhaps I'm missing something here, but I do not see any security in
this solution, except for the user not having to enter his Twitter
credentials in an app that only he uses anyway.
Open source means, well, open (readable and modifiable by anyone)
source. Meaning, your API Consumer Key is
The problem here is that Twitter wants to use OAuth to identify and
block abusive applications, but the OAuth standard was not designed to
be used in that manner. Regardless of whether an application's source
code is published, the consumer secret key will always be easily
accessible in desktop
I don't understand why you are suggesting this only for open source
programs. Were you thinking that an attacker would be incapable of
decompiling an executable and extracting the secret?
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
A solution, maybe, for desktop folks who can C+P a large string
(although I'm willing to bet you'll have a lot of breakdown there),
but it will fail miserably on mobile apps. The string is way, way too
long. This will get screwed up badly by non-technical users.
(Yes, some people make open-source
As it was explained to me (I think the API team would do well by
discussing this stuff out in the open so we don't have to answer for
them), the concern is having keys available in plain text. with OSS,
you have that in 1, and potentially 2, situations:
1: Source code distributions/repos
2:
obfuscate your code (compiling, or intentional obfuscation)
So OAuth's security is based on obscurity? That's pretty lame.
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 Jun 12, 10:16 am, Taylor Singletary taylorsinglet...@twitter.com
wrote:
(This is the other side of the coin.. on one side of the coin you have the
advantage that OAuth applications keep working even if the user changes
their password (YAY!) and then you have on the side of the coin that
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
On Jun 12, 11:49 am, Bernd Stramm bernd.str...@gmail.com wrote:
secure against what?
The threat that OAuth's security-through-obscurity fails to protect
against is rogue-app B doing something bad while using legit-app A's
stolen credentials. The author of app A gets blamed for app B's bad
I love this idea!
But why don't you use verifier instead of such a long string?
ck=KIyzzZUM7KvKYOpnst2aOwcs=4PQk1eH4MadmzzEZ1G1KdrWHIFC1IPxv1kXZg0G3Eat=5
42212-
utEhFTv5GZZcc2R4w6thnApKtf1N1eKRedcFJthdeAats=FFdeOEwxOBWPPREd55
dKx7AAaI8NfpK7xnibv4Yls
I don't want to copypaste such a string on
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 higher
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 would be
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
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 the control of
potentially untrusted parties. For example, if the client is a
desktop application with
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
Interesting idea.
On Jun 11, 6:56 pm, Taylor Singletary taylorsinglet...@twitter.com
wrote:
Hi Developers,
As has been discussed on the list recently, OAuth and Open Source
applications are a difficult combination because token secrets shouldn't be
embedded in widely distributed code.
This is excellent news and sounds like a much better user experience
than the previously discussed options. I would like to suggest it be
taken one step further. Could the encoded string with the keys be
returned programatically to the Open Source application instead of
asking the user to
57 matches
Mail list logo
