On Raffi's queue...

Any request you make following the request token step requires a minor
alteration to how your signing key is used.

Instead of providing your signing secret as "{consumer_secret}&" while
signing your signature base string, you'll use
"{consume_secret}&{oauth_token_secret}" And you'll of course first
URL-encode both the consumer secret & token.

This is true of the access token step and any resource requests you make
that require user authorization.

When you receive a request token from Twitter, you receive both an
oauth_token and oauth_token_secret. The oauth_token is what you send back to
us, the oauth_token_secret is what you use in conjunction with your
consumer_secret to sign the request. Both pieces of data (the token and the
secret) make up the "request token" when thought of as an object.

All of this is because two layers of secrets is better than one. Like doubly
stuffed oreos.

Similarly, when you exchange that request token for an access token, you're
going to be presented again with an oauth_token and oauth_token_secret. At
this stage of the game, these two pieces are you're "access token" object.
Just like with the oauth_token_secret in the step above, you use this in
conjunction with your consumer_secret to sign the signature base string.

Finally, ensure that the oauth_verifier is part of your signature base
string as well as your authorization header on the access token exchange
step. oauth_* parameters belong in both locations, alphabetically sorted
such that oauth_verifier would occur just prior to oauth_version.

Some other advice based on the examples you've shown:
  * Use SSL instead for all OAuth-based token negotiation steps
  * Use api.twitter.com as the domain for the OAuth token negotiation steps,
as well as resource requests

Good luck!

Check out the OAuth dancer, it's a tool I made to help provide as much debug
information as possible on theoretically to-spec API requests:
http://bit.ly/oauth-dancer

Taylor Singletary
Developer Advocate, Twitter
http://twitter.com/episod


On Wed, Mar 24, 2010 at 10:24 PM, Raffi Krikorian <ra...@twitter.com> wrote:

> hi!
>
> i'm sure taylor will kick in with a larger knowledge drop, but what i can
> suggest is taking a look at and playing with
> http://hueniverse.com/2008/10/beginners-guide-to-oauth-part-iv-signing-requests/.
>  that has a pretty good interactive example that you can mimic.
>
>
> On Wed, Mar 24, 2010 at 6:14 PM, Grantcv1 <grant.vergott...@gmail.com>wrote:
>
>> Hi, After three days of working my way through OAuth, I am getting
>> tired and frustrated. I am so close yet so far.
>>
>> 1) So far I have registered my application and got the consumerKey &
>> secret
>> 2) I have used those to get the request token & secret. I was able to
>> generate the correct signature to get this wor work.
>> 3) I have used the token to login to twitter and allow my app access.
>> With that I get a PIN.
>> 4) I am using the PIN as the oauth_verifier.
>> 5) I am trying to get the access token now.
>>
>> I am using the same algorithm to generate the signature that I use
>> without fail to create the signature to get the request token (so it
>> has worked correctly), with the exception that I have the added
>> oauth_token and oauth_verifier parameters. I think that everything is
>> encoded and sorted correctly. The parameters I use to create the
>> signature is shown in this pseudo base-string:
>>
>> POST&http://twitter.com/oauth/access_token&oauth_consumer_key=<ck-
>> encoded>&oauth_nonce=<nonce-encoded>&oauth_signature_method=<signature-
>> method-encoded>&oauth_timestamp=<timestamp-
>> encoded>&oauth_token=<request-token-encoded>&oauth_verifier=<pin-
>> encoded>
>>
>> In addition, the URL part is RFC3986 encoded as well as everything
>> after the second & (all the params in a single string).
>>
>> This complete string is then hashed using HMAC-SHA1 with the
>> ConsumerSecret.
>>
>> I never seem to use the token secret so I don't know what that is
>> for???? What am I doing wrong at this point?
>>
>> To unsubscribe from this group, send email to twitter-development-talk+
>> unsubscribegooglegroups.com or reply to this email with the words "REMOVE
>> ME" as the subject.
>>
>
>
>
> --
> Raffi Krikorian
> Twitter Platform Team
> http://twitter.com/raffi
>
> To unsubscribe from this group, send email to twitter-development-talk+
> unsubscribegooglegroups.com or reply to this email with the words "REMOVE
> ME" as the subject.
>

To unsubscribe from this group, send email to 
twitter-development-talk+unsubscribegooglegroups.com or reply to this email 
with the words "REMOVE ME" as the subject.

Reply via email to