Thanks for clarifying ^^

Arthur.

2010/6/2 Taylor Singletary <taylorsinglet...@twitter.com>

> Hi Arthur,
>
> Indeed it is a Quest.
>
> You don't need to do this entire round trip every single time. In Twitter's
> OAuth implementation, when we respond with the access token to you in the
> access token step, we also include the screen_name and id of the user. You
> in turn should store the id, screen_name, oauth_token, and
> oauth_token_secret for the user in whatever representation you like.
>
> Then, you use the access token to perform your resource-based API calls
> from that point forward.
>
> You only need to do the whole OAuth song & dance once for each user (or
> until the access token is revoked by the user, or if you otherwise want to
> validate identity for some reason).
>
> Some OAuth libraries make it difficult to consume the additional query
> parameters returned to you in the access token step. If this is the case,
> you can make your first API call to
> http://api.twitter.com/1/account/verify_credentials.json or .xml, which
> will return information you need about the user in a format you can easily
> consume.
>
> Taylor
>
> On Wed, Jun 2, 2010 at 1:19 PM, Arthur Pires <arthur...@gmail.com> wrote:
>
>> After some work (and some help from the group) my implementation works,
>> but...
>>
>> The QUEST to get an access token
>>
>>    1. app gets a request token from twitter
>>    2. user clicks a button on the ap
>>    3. app opens a twitter page, user types username/password
>>    4. twitter gives user a PIN
>>    5. user use this PIN in the application
>>    6. GREAT, finally app exchange the request token for an access token
>>
>> This token belongs to who? I mean, i don't even know his username!
>> The user will have to repeat the steps above *every time*?
>>
>> I have no idea on how to fit oauth in a real application, i'm probably
>> missing something :/
>>
>> Thanks in advance.
>>
>> Arthur.
>>
>
>

Reply via email to