I think the thinking is, the first time a user authenticates using our app, we get the access token and it's up to us to persist the secret. Then we can use the authenticate approach, get back the user's token (it should be the same one we have), and then match it up to the access token paired to it.
So, yeah I think this makes the scenario where you want a simple app that uses cookies not plausible for the authenticate scheme. You're better off running authorize each time for those, or at most, just when you no longer have the secret in hand. So Twitter as auth provider, not quite. On Apr 17, 8:29 am, Dossy Shiobara <[email protected]> wrote: > On 4/16/09 10:56 PM, Dimebrain wrote: > > > It should be no different than if you persisted the access token > > yourself and went to call the API a few weeks after doing so, you > > should be able to trust that your token won't expire. > > But this still leaves the question of "how do I get and/or know the > token secret for the returned AccessToken" ... this is the current > execution path: > > Consumer invokes oauth/request and receives a RequestToken and > corresponding token secret. Consumer directs user to oauth/authenticate > with RequestToken. Assuming user authenticates and authorizes the > application, Provider directs user back to callback URL with an > AccessToken. Consumer now has a RequestToken and secret, and > AccessToken without its secret. > > That AccessToken is effectively useless to the Consumer. > > -- > Dossy Shiobara | [email protected] |http://dossy.org/ > Panoptic Computer Network |http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70)
