Ok so you guys are saying store the access token in the db. Im getting hung up on how you would authenticate this user at a later point without making them reauthenticate through twitter to make sure who they say they are.
First Authentication User comes to site -> twitter auth (type in username/pass) -> twitter auth (do you want to allow app) -> back to site (store access tokens) Later Authentication on a diff computer per say User comes to site -> twitter auth (type in username/pass) -> ?? (do something with access token) ?? -> back to site Something like if user and pass are valid then get the access token from the db and start doing w/e you wanted to do? Is this the flow that im missing? On Oct 21, 8:08 pm, ryan alford <[email protected]> wrote: > The access token doesn't expire. It's also specific for the user. > There is no reason for you to get rid of it. > You should store it with a relation to the username. The user should > not be forced to re-allow every session. > > On Oct 21, 2009, at 7:44 PM, shawninreach <[email protected]> > wrote: > > > > > Im a little confused on why some people are saying you want to store > > the access token after you get it. Dont you just want to keep it in > > the session until the session expires or the user clears cookies? I > > understand how to use the access token, im just confused on after the > > session is expired your going to need to make the user click "I Allow" > > later again and theres nothing that can be done about that and you > > request new tokens so why store them in the database at all. Basically > > im just trying to understand this process a bit more so I can safely > > store only what I absolutely need to. Thanks guys for the help! > >
