See Twurl:
http://thechangelog.com/post/536535280/twurl-oauth-enabled-curl-for-the-twitter-api
and
http://github.com/marcel/twurl
+Clint
On Thu, Apr 29, 2010 at 9:47 PM, mcfnord mcfn...@gmail.com wrote:
I think I know the answer to this question (YES), but I wanna clarify:
Everywhere in the
On Sat, Apr 17, 2010 at 8:09 AM, sdesapio sdesa...@gmail.com wrote:
Classic ASP VBScript OAuth library and example project:
http://scottdesapio.com/VBScriptOAuth/
:)
My hero! (Although I am still waiting for Twitter to complete its 2
legged oauth.)
--
Subscription settings:
this is part of the oauth rewrite that we mentioned at chirp - we hope to be
rolling it out soon.
On Sat, Apr 17, 2010 at 7:17 AM, Lil Peck lilp...@gmail.com wrote:
On Sat, Apr 17, 2010 at 8:09 AM, sdesapio sdesa...@gmail.com wrote:
Classic ASP VBScript OAuth library and example project:
marcel (@noradio) and i have been working on http://github.com/marcel/twurl --
there is definitely some work that needs to be done, but we're getting
close.
On Tue, Apr 13, 2010 at 9:01 PM, TJ Luoma luo...@gmail.com wrote:
On Tue, Apr 13, 2010 at 7:35 PM, Raffi Krikorian ra...@twitter.com
in my ideal world, nobody would have access to a user's password except
twitter.com -- oauth provides a framework so end applications are not
storing the actual password. people are notoriously bad with using the same
password on lots of different sites. additionally, oauth provides twitter
- Raffi Krikorian ra...@twitter.com wrote:
in my ideal world, nobody would have access to a user's password
except twitter.com -- oauth provides a framework so end applications
are not storing the actual password. people are notoriously bad with
using the same password on lots of
-dev] Re: Basic Auth Deprecation
in my ideal world, nobody would have access to a user's password except
twitter.com -- oauth provides a framework so end applications are not
storing the actual password. people are notoriously bad with using the
same password on lots of different sites
Why are you Twitter guys pushing xAuth so hard? Even for new desktop
clients? Instead of recommending a proper oAuth flow with PIN or such?
I understood its main purpose is to help legacy clients with
transition, and new clients should do proper oAuth.
I can tell you that there are many
*Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation
in my ideal world, nobody would have access to a user's password except
twitter.com -- oauth provides a framework so end applications are not
storing the actual password. people are notoriously bad with using the same
password on lots
On Wed, Apr 14, 2010 at 8:39 AM, Dean #39;at#39; Cognation dot Net
d...@cognation.net wrote:
But why is oauth better than basic for a desktop client?
i understand it for the webapps but on a desktop client whats the
point?
Basically you are saying the desktop end user cant be trusted? Sorry
-development-t...@googlegroups.com] *On Behalf Of *Raffi Krikorian
*Sent:* Wednesday, April 14, 2010 8:59 AM
*To:* twitter-development-talk@googlegroups.com
*Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation
in my ideal world, nobody would have access to a user's password except
twitter.com
i would love it to :P
On Wed, Apr 14, 2010 at 6:18 AM, zn...@comcast.net wrote:
- Raffi Krikorian ra...@twitter.com wrote:
in my ideal world, nobody would have access to a user's password
except twitter.com -- oauth provides a framework so end applications
are not storing the actual
we developed xauth specifically for that - mobile and desktop clients were
complaining about usability problems when they have to bounce their users to
a web browser. i'm well aware of the implications about xauth, and have
blogged about it here:
xauth is definitely useful for the browserless case.
On Wed, Apr 14, 2010 at 6:33 AM, Cameron Kaiser spec...@floodgap.comwrote:
Why are you Twitter guys pushing xAuth so hard? Even for new desktop
clients? Instead of recommending a proper oAuth flow with PIN or such?
I understood its main
[mailto:twitter-development-t...@googlegroups.com] On Behalf Of Raffi
Krikorian
Sent: Wednesday, April 14, 2010 10:08 AM
To: twitter-development-talk@googlegroups.com
Subject: Re: [twitter-dev] Re: Basic Auth Deprecation
again - overly dramatic.
everything i said above still stands - it provides
Subject: Re: [twitter-dev] Re: Basic Auth Deprecation
we developed xauth specifically for that - mobile and desktop clients were
complaining about usability problems when they have to bounce their users to
a web browser. i'm well aware of the implications about xauth, and have
blogged about
@googlegroups.com
*Subject:* Re: [twitter-dev] Re: Basic Auth Deprecation
in my ideal world, nobody would have access to a user's password except
twitter.com -- oauth provides a framework so end applications are not
storing the actual password. people are notoriously bad with using the same
password
OAuth was intended to facilitate inter-platform user account access without
requiring actual usernames or passwords to be exchanged. This would allow
platforms such as Twitter, Facebook, TwitPic, etc. to access each others
user accounts while maintaining the privacy of that user's access
We're getting ready to release a few changes to our oauth
implementation that will allow two legged oauth for public methods.
On Apr 14, 2010, at 9:16 AM, Lil Peck lilp...@gmail.com wrote:
On Tue, Apr 13, 2010 at 11:01 PM, TJ Luoma luo...@gmail.com wrote:
I'm still unclear what people
I am all for oAuth replacing basic, but one of the remaining issues is
consumer keys. With 1.0 signing is required thus requiring
distributing keys with your application. We all know this is pretty unsafe
since any hacker could yank them out.
oAuth 2.0 does seem to solve a lot of the issues
yes, it could be a problem - however, there are known solutions to
obfuscating and keeping your consumer key secret. not perfect, but pretty
good. maybe we can start a discussion around this? people are going to
need to start to move towards this method, and we are here to help you if
you need
On Wed, Apr 14, 2010 at 18:26, Raffi Krikorian ra...@twitter.com wrote:
yes, it could be a problem - however, there are known solutions to
obfuscating and keeping your consumer key secret. not perfect, but pretty
good. maybe we can start a discussion around this?
What's the known solution
yes, it could be a problem - however, there are known solutions to
obfuscating and keeping your consumer key secret. __not perfect, but pretty
good. __maybe we can start a discussion around this?
What's the known solution for an open-source Web-based application
that I want to distribute
Why not just distribute a key with it? The worst that happens is someone
uses it in their app and it gets disabled and some people get pissed off at
you. I have yet to hear of this happening to a Twitter application. If
someone abuses your key and Twitter does not handle the situation well I
will
we'll make sure to message it long before hand!
On Tue, Apr 13, 2010 at 4:30 PM, Dewald Pretorius dpr...@gmail.com wrote:
Could you please announce the hard turn off date somewhere on one of
your Twitter blogs about a month ahead of time, so that we all have an
official source to point our
Just so I understand this, applications running on the desktop will still work
correct? Basic functionality is only being turned off for web apps correct?
It's not like desktop apps will have to start using oauth.
Cheers,
Dean
-Original Message-
From:
On Tue, Apr 13, 2010 at 7:35 PM, Raffi Krikorian ra...@twitter.com wrote:
we'll make sure to message it long before hand!
I'm still unclear what people who use 'curl' will do after basic auth
is deprecated.
Is there an OAuth for the commandline? If so: pointers, please.
TjL
yes, it's official. The depreciation of Basic Auth will start in June.
Ryan
On Mon, Jan 18, 2010 at 10:57 AM, Hwee-Boon Yar hweeb...@gmail.com wrote:
Thanks. Hope it's not official. I don't remember reading anything like
that on the 2 lists.
--
Hwee-Boon
On Jan 18, 7:01 pm, Rich
Thanks. Hope it's not official. I don't remember reading anything like
that on the 2 lists.
No, it wasn't posted here at the time. I insert a fairly loud *ahem* to
ensure such things are posted here also in the future.
--
personal:
we have a command line tool that acts exactly like curl but does all the
oauth signatures transparently to the end user (the user simply needs to
register the keys with the tool). this way people who rely on the ability
to use curl to interact with the API (such as scripts, etc.) can still do
so.
On Mon, Jan 18, 2010 at 12:48 PM, Raffi Krikorian ra...@twitter.com wrote:
we have a command line tool that acts exactly like curl but does all the
oauth signatures transparently to the end user (the user simply needs to
register the keys with the tool). this way people who rely on the ability
Thanks for your reply!
Couldn't I just save the access token in a database and use it later?
Yup. Many, if not most, applications do just that.
--
personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com *
32 matches
Mail list logo
