Bad access token?

[oz]

I'm getting this error when trying to authorize:

Woah there!
This page is no longer valid. It looks like someone already used the
token information you provided. Please return to the site that sent
you to this page and try again … it was probably an honest mistake.

This seems to be the standard message for a bad access token because
replacing the token with random jibberish from the url in my browser
produces the same result.

I am using the oauth_token specified on my application's "Access Token
Requisition" page. I've tried with an without the oauth_callback
param specified. I just set up the application today.

[Tom van der Woerdt]

I've never seen that error before, but I assume that it's your
oauth_nonce that is invalid (not unique). If it is not the oauth_nonce,
you should re-check your oauth_timestamp value. It should be in Unix
Timestamp format (UTC) and it should not be more than 5 minutes off.

Tom

On 12/17/10 9:48 AM, oz wrote:
> I'm getting this error when trying to authorize:
>
> Woah there!
> This page is no longer valid. It looks like someone already used the
> token information you provided. Please return to the site that sent

> you to this page and try again � it was probably an honest mistake.

[Taylor Singletary]

It sounds like you might be using the wrong tokens in a few places.

Just a quick review of what tokens are used where in these steps:

Your consumer key and consumer secret are used in every step of the OAuth negotiation process and every API call you make. Access tokens are only used on resource-based requests to the API itself.

Your first request, to /oauth/request_token, should not include a value for oauth_token (but you should be including an oauth_callback, regardless of whether you set it on you application record or not). The request token step yields the first oauth_token and oauth_token_secret (request token) as its response. 

The second step is then sending that request token as an oauth_token (properly integrated into your OAuth headers, basestring, and signature) to the /oauth/authorize page (with no oauth_callback specified at this phase, as the value is taken from the previous step).

When this step succeeds, it redirects to the oauth_callback specified on the request token step. The callback will receive an oauth_verifier, in addition to the same oauth_token "request token" value.  Now the request token is sent to the /oauth/access_token (again properly signed) in exchange for an access token (represented again, by key/value pairs for oauth_token and oauth_token_secret). These are the two values that you need to persist.

Finally, if you registered your application, and then went to the "My Access Token" feature on the right-hand pane, you would have the oauth_token and oauth_token_secret values that would be produced in the final step for your own account.. essentially, you start from the point of being able to use the access token to make API calls.

Hope this helps.

Taylor

--
Twitter developer documentation and resources: http://dev.twitter.com/doc
API updates via Twitter: http://twitter.com/twitterapi
Issues/Enhancements Tracker: http://code.google.com/p/twitter-api/issues/list
Change your membership to this group: http://groups.google.com/group/twitter-development-talk