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
I don't feel that OAuth is a good solution for desktop applications.
If a user doesn't want the application to access their Twitter
account, why'd they download it in the first place? It seems very
redundant.
But the real problem is for mobile devices, especially for devices
that don't ha
Hi Kevin,
With basic auth, its nice because you can use those credentials anywhere. I
*was* working on a collaboration site, until I heard basic auth was going
away, because I was able to use credentials for dozens of services around a
single profile.
I asked the same question about oAuth, i.e. ca
When a user signs up at TwitPic, for instance, the same credentials
they used for Twitter are now valid for use in uploading media. This
lets users enjoy a bit of a mash-up with a single sign-on. Is this
also true when authorized via openAuth?
--
Kevin Mesiab
CEO, Mesiab Labs L.L.C.
http://tw
looks like a clone of tweetmeme.com
On Aug 15, 9:18 pm, Kevin Mesiab wrote:
> Thanks, here's a little sneak preview (attached).
>
>
>
> On Sat, Aug 15, 2009 at 3:13 PM, Jesse Stay wrote:
> > Considering Twitter's recent move, you guys have a GREAT URL (retweet.com).
> > Can't wait to see what yo
On Sun, Aug 16, 2009 at 7:08 AM, Nicole Simon wrote:
>
>
> On Sat, Aug 15, 2009 at 22:26, Kevin Mesiab wrote:
>>
>> The interaction seems unintuitive and redundant for users who have
>> already granted our application 'trust' by installing it.
>
> I can't understand this notion.
> Every single da
On Sat, Aug 15, 2009 at 22:26, Kevin Mesiab wrote:
> The interaction seems unintuitive and redundant for users who have
> already granted our application 'trust' by installing it.
I can't understand this notion.
Every single day users are sheep enough to do stupid things -
they just need to be
Looks nice. Seems like a Digg for twitter almost. Look forward to seeing it
in action.
On Sat, Aug 15, 2009 at 9:18 PM, Kevin Mesiab wrote:
> Thanks, here's a little sneak preview (attached).
>
>
> On Sat, Aug 15, 2009 at 3:13 PM, Jesse Stay wrote:
> > Considering Twitter's recent move, you guys
Considering Twitter's recent move, you guys have a GREAT URL (retweet.com).
Can't wait to see what you guys do with that.
Jesse
2009/8/15 Kevin Mesiab
>
> Hi Twitter API Team,
>
> We are considering not implementing OAuth in our desktop application.
> The interaction seems unintuitive and redund
No OAuth = no source attribute unless your application was
"grandfathered in".
On Aug 15, 4:26 pm, Kevin Mesiab wrote:
> Hi Twitter API Team,
>
> We are considering not implementing OAuth in our desktop application.
> The interaction seems unintuitive and redundant for users who have
> already g
28 matches
Mail list logo