nor can oauth assure the provider that a desktop app is legitimate when
the app authenticates itself to the provider.
John Kristian wrote:
> An OAuth Consumer that's deployed to users' desktops or mobile devices
> can't keep a secret. One should assume its consumer key and consumer
> secret will
This issue has been discussed at http://groups.google.com/group/oauth?hl=en
You might might find that informative. Some highlights:
An OAuth Consumer that's deployed to users' desktops or mobile devices
can't keep a secret. One should assume its consumer key and consumer
secret will be known to
I'm sorry, I was talking about distributing source code. However, I
wasn't thinking of Open Source (even though I wrote that), I was
thinking of things like interpreted languages (like PHP) where you
would distribute an application that can't be compiled in to a binary,
as, even if you don'
I still didnt get this
Just to make my question clear
How are you going to obtain tokens for *other *users using the application
itself?
The worst you can do is use the key/secrets to trap *new *users by building
a brand new app
(with the stolen consumer key/secrets. And new clients have to trust t
On Aug 17, 4:55 pm, Chris Babcock wrote:
> Silly me. I thought someone was talking about distributing source code.
> Building an enduser distribution is somewhat to entirely different.
That's what I was getting at when I said "a desktop or mobile device
application - open source or closed". I
On Tue, 18 Aug 2009 02:52:24 +0530
srikanth reddy wrote:
> <<
> It's worse than that. You don't even have to intercept the key, just
> use the application itself to obtain tokens for other users' accounts.
> How are they going to tell the difference between their copy of TweetX
> and someone els
<<
It's worse than that. You don't even have to intercept the key, just
use the application itself to obtain tokens for other users' accounts.
How are they going to tell the difference between their copy of TweetX
and someone elses' in their auth dialogs?>>
Sorry. I didn't get this. How are you go
On Mon, 17 Aug 2009 23:32:58 +0530
srikanth reddy wrote:
> @chris
> You cannot ask every user to get new consumer token/secret.
> There is no way you can protect a consumer secret.
I did have a blind spot operating here. When someone says, "Open
Source," I'm usually thinking server software not
Silly me. I thought someone was talking about distributing source code.
Building an enduser distribution is somewhat to entirely different.
First, there really isn't any point to using OAuth for a client unless
the client code lives on the network. The whole advantage of the scheme
is that the us
This is a good discussion - I've yet to find a canonical answer for how this
*should* be done for client-side/consumer apps.
If you are distributing a server application, then putting the application
registration instructions in a README is perhaps not such a big deal.
Desktop/mobile apps are anot
@chris
You cannot ask every user to get new consumer token/secret.
There is no way you can protect a consumer secret.
@Joseph
<>
As far as i know this is the best way to hide the consumer secret. This will
not stop a determined user who try to intercept the keys but you have the
option of changing
This is interesting Chris, as I have had the same question. How would
you propose to distribute a usable FLOSS twitter app that uses Oauth to
authenticate itself but doesn't include the app's consumer key and
consumer secret? fetch the key and secret at runtime from a secure
server somewhere? t
> > > When you know your code is going to be seen you either avoid doing
> > > stupid things like hard coding credentials or you learn fast that
> > > configuration data is not code.
> >
> > Fair enough. So how do you do it? How do I distribute a desktop or
> > mobile device application - open so
exactly. and for those who think their closed-source oauth app hides
their app key and secret, have you ever run "strings" on your binary?
(for those keeping score, it's basic auth: 2, oauth: 0)
thanks!
Joseph Cheek
@cheekdotcom
JDG wrote:
> Which eliminates one of the biggest features of OAu
Which eliminates one of the biggest features of OAuth for a lot of
app-writers -- the ability to put their app in the "source" parameter, thus
eliminating the biggest piece of marketing they have.
On Mon, Aug 17, 2009 at 08:59, Chris Babcock wrote:
>
>
> > On Aug 17, 6:27 am, Chris Babcock wrot
> On Aug 17, 6:27 am, Chris Babcock wrote:
>
> > When you know your code is going to be seen you either avoid doing
> > stupid things like hard coding credentials or you learn fast that
> > configuration data is not code.
>
> Fair enough. So how do you do it? How do I distribute a desktop or
>
On Aug 17, 6:27 am, Chris Babcock wrote:
> When you know your code is going to be seen you either avoid doing
> stupid things like hard coding credentials or you learn fast that
> configuration data is not code.
Fair enough. So how do you do it? How do I distribute a desktop or
mobile device
" I'll ask them for a username and password, and log them into OAuh
myself without them having to ever see a web browser."
Announcing that your application is doing an end-run around Twitter's
authentication protocols is a great way to get your app shut down.
Also, your application is likely to b
On Sun, 16 Aug 2009 18:49:49 -0400
Jason Martin wrote:
> On another note, how "Open Source friendly" is OAuth? I'm not sure
> if people who write open source software want to be giving out their
> Consumer Secret key in their source code
Reasoning from a faulty premise.
When you know your co
19 matches
Mail list logo
