@googlegroups.com
Sent: Wednesday, May 6, 2009 6:11:46 PM
Subject: [twitter-dev] Re: The OAuth Conundrum
On Wed, May 6, 2009 at 18:05, MPS mpelzsher...@gmail.com wrote:
I thought I'd add my $.02 to this thread.
I'm working on an iPhone app that uses the Twitter API.
This is a side project for me
, 2009 6:11:46 PM
Subject: [twitter-dev] Re: The OAuth Conundrum
On Wed, May 6, 2009 at 18:05, MPS mpelzsher...@gmail.com wrote:
I thought I'd add my $.02 to this thread.
I'm working on an iPhone app that uses the Twitter API.
This is a side project for me with a small budget and tight
I thought I'd add my $.02 to this thread.
I'm working on an iPhone app that uses the Twitter API.
This is a side project for me with a small budget and tight timelines.
I'm using Matt Gemmel's Objective-C library to integrate with Twitter.
Everything was going along smoothly, until I realized
On Wed, May 6, 2009 at 18:05, MPS mpelzsher...@gmail.com wrote:
I thought I'd add my $.02 to this thread.
I'm working on an iPhone app that uses the Twitter API.
This is a side project for me with a small budget and tight timelines.
I'm using Matt Gemmel's Objective-C library to integrate
I've done a lot of work recently with Twitter's oAuth implementation.
I'm happy with the the solution for my web apps. Having said that, I
don't think it should be the way to authenticate. Basic Auth has
been so easy to implement that I think it has fostered very creative
solutions from people
It is a case of tool maturity, but it's a heck of a steep hill to
climb up when comparing HTTP Basic Auth to any alternatives.
Comparable toolsets for a wide range of languages and environments
won't be available for a long time, if ever.
In addition, my real concern, as stated above, is with
I, too, have a bunch of automated scripts accounts that I will be
attempting to move to OAuth in the near future. My plan is just to
create a dummy app under my main account and then write a simple
Get Your Access Token page on my website and use it for each of my
bot accounts to create and save
On Fri, Mar 27, 2009 at 11:00 AM, Chad Etzel jazzyc...@gmail.com wrote:
Anyone else dealing with the script/automation issue in a different manner?
That's pretty much going to be my plan. Dummy Script Automation of
Doom Application and then just a basic webapp that auths and does
it's thing
Seriously guys, whats the point in implementing OAuth for stuff like
this? Why do you need to delegate access rights to your scripts, your
scripts _are_ you, acting as a proxy to the Twitter API as you.
OAuth is for delegating access to a third party and is not the right
tool for this job,
On Fri, Mar 27, 2009 at 12:33 PM, Joshua Perry j...@6bit.com wrote:
Seriously guys, whats the point in implementing OAuth for stuff like this?
Why do you need to delegate access rights to your scripts, your scripts
_are_ you, acting as a proxy to the Twitter API as you.
If Basic Auth is
Thats exactly what I am saying, just because OAuth is the hammer that
the Twitter developers are providing to solve the third party delegation
problem doesn't make every problem a nail, and I don't understand why
everyone is jumping on board trying to shoehorn OAuth into every
authentication
It seems to me that Twitter themselves have said (or at least heavily
implied) that Basic Auth will GO AWAY in the future. Therefore, OAuth
will be the ONLY hammer to use when driving nails.
Now, if that stance has changed and Basic Auth will be available
forever more, then I am more than happy
Hello there,
It seems there have been a few threads lately that end in
frustration about Basic Auth going away. Going into the OAuth beta we
were thinking that we would ideally [1] turn off Basic Auth in the
future. Based on the feedback (that's what betas are for, right?)
we've seen
On Fri, Mar 27, 2009 at 4:04 PM, Matt Sanford m...@twitter.com wrote:
The low barrier to entry with the Twitter API it a great feature we
don't want to lose. We think about it often, and I think about it all of the
time in relation to OAuth. I see this as a concern as much as cron jobs and
Hi Paul,
In a reply to a previous thread today I mentioned we're working
on making that login scenario easier. I am working on it as we speak
(or, type, rather).
Thanks;
— Matt
On Mar 27, 2009, at 02:32 PM, Paul Kinlan wrote:
Hi matt,
I generally like the idea and implementation
On 26 Mar 2009, at 16:14, Joshua Perry wrote:
My friend sent me this blog post [1] (I believe the author is on this
list) and though I agree with it generally there is one sentence that
really stood out to me it's a fantastic solution to _authenticate
other
web apps_. After mulling
My friend sent me this blog post [1] (I believe the author is on this
list) and though I agree with it generally there is one sentence that
really stood out to me it's a fantastic solution to _authenticate
other
web apps_. After mulling this over I think that this sentence should
Exactly how I feel Cameron. Use of HTTP Basic Auth has contributed
greatly to interesting, unexpected uses of the API, especially those
that involve automation. I absolutely feel that the availability of
OAuth is a Good Thing, and for many use cases it is practically
essential, but it is also
I'm not saying OAuth is a panacea, but it is better than handing over
a password.
That's the crux of it. It's not a panacea (the UX sucks, especially
for iPhone apps), but the fact is it's only marginally better than
handing over a password. I mentioned this in my blog post (linked
above),
I'm sorry, but I don't know how you can call this a common interface
between web apps and proxy apps. The only similarity is that they are
pushing a big green Accept button in both flows.
The big difference for a web application is the callback url and the
fact that the webapp is already
Fair point, there do seem to be more twitter apps than say Flickr apps,
but is this not just a case of tool maturity though?
It is hard to beat cron and curl, but tools like
http://intridea.com/2009/3/23/twitter-auth-for-near-instant-twitter-apps
will make it easier to get past the auth setup
See, I think the problem is that we are talking about two different
things in the same way. There is a big difference Proxy != Delegate!
OS's do have a built in proxy authentication scheme, Windows calls it
CardSpaces, everyone else calls it OpenID.
There is a standard credential - access
On Mar 26, 2009, at 10:34 AM, atebits wrote:
I'm not saying OAuth is a panacea, but it is better than handing over
a password.
That's the crux of it. It's not a panacea (the UX sucks, especially
for iPhone apps), but the fact is it's only marginally better than
handing over a password.
Wrong, if the app went rogue the user could uninstall it, or just not
run it. And like I said in my other message, you don't need to follow
the rules if you are trying to be evil, so the whole argument against
allowing proxy applications to exist just because one could go rogue is
a moot
First of all I agree wholeheartedly with the philosophy of shifting
control to users and Twitter. I disagree with the details of the
implementation. (In particular using the browser as a crutch).
Ah, but then your application would have the user's password.
I can get the users password
25 matches
Mail list logo
