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. >> > >