Clarifications:
The oauth_verifier is only necessary to retrieve an access token. Here's a
quick map of what elements you need to persist short-term vs long-term:
* You use your consumer key and secret to issue a request token request, in
response you get back two fields you need to persist in the short-term until
you have an access token: oauth_token and oauth_token_secret -- together,
these two fields make up your "request token"
* Once you have the request token, you create a Authorization URL which you
direct the user to browse to. This URL contains the oauth_token from the
previous step.
* The user authorizes your application, is presented with the oauth_verifier
PIN code, and is asked to enter it into your application.
* You collect the PIN code/oauth_verifier, and setup a request to exchange
the request token for an access token. You take your persisted request token
(and secret) from the first step, create an OAuth request with your
oauth_token set to the request token, set your oauth_verifier to the value
supplied by the user, and sign the request using a composite signing key
made up of your consumer secret and the oauth_token_secret from your request
token in step one. You don't need to persist your oauth_verifier at all --
simply use it in this access token step and then discard it.
* In exchange for the signed request containing the oauth_verifier and your
request token, you'll get a response containing the fields oauth_token and
oauth_token_secret again. This time, these fields collectively represent
your "access token". These are the values that you persist from this point
forward and use in each subsequent request on this user's behalf. The
oauth_token becomes the oauth_token field you send with every OAuth request,
and the oauth_token_secret becomes the second component to your composite
signing key (that, like the access token request, is used in conjunction
with your consumer secret).
In conclusion:
-- persist the oauth_token and oauth_token_secret from the request token
step short-term, until you've exchanged it for an access token
-- don't persist the oauth_verifier for longer than the time it takes you
to collect the verifier from the user and use in your "exchange request
token for access token" phase
-- persist the oauth_token and oauth_token_secret you receive from the
access token step ("your access token") for as long as you'll be making
requests as that user.
Hope this clears it up!
Taylor
On Mon, May 24, 2010 at 7:43 AM, Tonyw wrote:
> thanks for that :)
>
> so... and bear with me here, assuming i get that to work, i eventually
> get back an oauth_verifier and this is something i write down and keep
> forever for my app to use in the future to send tweets?
>
> and each time i send a tweet, i need to -
>
> use the oauth_verifier to get an access token (which works once)
>
> then send the tweet?
>
>
>
>
>
> On May 24, 3:24 pm, Taylor Singletary
> wrote:
> > Hi Tony,
> >
> > Yes, the documentation is yet to be written, but will be coming as soon
> as I
> > can finish it up.
> >
> > I'll be happy to help you through it until then though.
> >
> > To ready your application for out-of-band OAuth, first configure your
> > application on dev.twitter.com/apps to be a "Client" mode app (no
> callback
> > URL pre-supplied).
> >
> > For the majority of the documentation you find ahttp://
> dev.twitter.com/pages/auth-- your process is going to be exactly the
> > same.
> >
> > - On the request token step, instead of providing a dynamic
> oauth_callback
> > parameter, you will be supplying the string "oob" -- everything else
> about
> > the request is the same.
> > - After getting your request token, you send the user to the
> authorization
> > URL just as normal.
> > - When the user provides their login information, instead of being
> > redirected to your application, they are presented with a page containing
> a
> > short set of characters that they are asked to enter into your
> application
> > - You provide a user interface in your application that collects the
> PIN
> > code (also known as the "oauth_verifier"). Then you build an access token
> > exchange request, exactly like the standard access token request, except
> you
> > provide the oauth_verifier you retrieved from the user. In standard OAuth
> > flows, the oauth_verifier would have been given to you in your
> > oauth_callback.
> >
> > Everything else about this flow is exactly the same.
> >
> > The only gotcha here is that a single application has to choose to either
> be
> > an "out of band" / "desktop client" application OR a dynamic web
> application
> > with dynamic callback URLs.
> >
> > Taylor
> >
> > Taylor Singletary
> > Developer Advocate, Twitterhttp://twitter.com/episod
> >
> >
> >
> > On Mon, May 24, 2010 at 6:59 AM, Tonyw wrote:
> > > I'm thinking (or was) of using the new oauth in a c++ app. But the
> > > docs are vague to say the least.
> >
> > > Given that this is actually missing -
> >
>
