First /authorize, than /authenticate. Ok, but how?

[Graardor]

Hi all. I’m trying to solve a problem I’ve encountered few days ago but I really can’t understand how.

Here’s the problem: as only /authorize can be used to grant a DM-capable access token and my app needs that ability, I have to use /authorize the first time a user try to access it. Then, on subsequent auths, I’d like to use /authenticate to auto-redirect him to my callback url. Ok. Perfect. But…how can I understand if the user has already authorized my app? I mean, when I obtain the acces token I know “everything” about the logged user but how can I know, for example, his ID o screen name BEFORE the redirection? If I know the user ID or screen name I can check on my DB if the user has already authorized my app. If so, I redirect him to an /authenticate url, otherwise to a /authorize.

For example, whit https://twitter.com/sessions/present.json you can understand if there is a user logged or not. I’d like something like that (or more “difficult”, of course) to know his screen name or ID too. Is that possible?

Thanks.

[episod]

You can’t know the screen name or user ID of the user visiting your site from any information Twitter can give you. Some developers use the session to hold this state information – if the long-lived session state doesn’t exist, kick the user to /oauth/authorize instead of /oauth/authenticate – if the session state does exist, kick the user to /oauth/authenticate

You may find it easier to just minimize the possible paths by utilizing /oauth/authorize the whole way through.