[twitter-dev] #oob missing?

[Tonyw]

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 -

http://dev.twitter.com/pages/auth#oob

is there any hope!?

;)

tony

[Taylor Singletary]

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 a http://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, Twitter
http://twitter.com/episod

[ramy]

sorry to jump in like this, but i've followed the authentication steps
and the server never responds, i started a thread earlier this week
detailing my problems here:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/a7e0f3968c6eed74

I've tested the encoding and signing process against the test strings
provided in the docs, and everything checks out, The authorization
header IS in fact being sent but the server never responds.

tips?

r.d.

On May 24, 10:24 am, Taylor Singletary <taylorsinglet...@twitter.com>
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

[Tonyw]

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 <taylorsinglet...@twitter.com>
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

[Taylor Singletary]

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

[Taylor Singletary]

r.d.,

I'll follow up with you on that in the other thread.

T