On Thu, Mar 26, 2009 at 7:30 PM, Elliott Kember <[email protected]> wrote: > >> If you don't have a database storing the access tokens or indefinite >> sessions on your webserver storing them, then the user will have to >> login everytime. There's no way to get an access token without users >> going through the OAuth detour. >> -Chad > > That's true - but what if the OAuth detour recognizes that the app is > already registers, and invisibly allows the authorization, and > redirects them to the callback url? For a web-app, this is perfect - > it's an invisible roundtrip, similar to OpenID's one. The user > probably wouldn't even notice.
I guess that would work if the user is already logged into twitter's website and has an active cookie/session going on... but what if they want to login as another user? The auto-callback wouldn't let them do that... They'd have to log out of twitter's website first, but how would they be informed to do that? -Chad > > In effect, I'm re-authorizing every time, and getting a new access > token each time. This will only work for web-apps - but the upside is, > a single button-click and you're logged in. > >> Won't have "read only access" accomplish this? You can check >> verify_credentials and never check anything else... but the OAuth >> login flow remains the same.. > > Sort of - but read-only access can still read DM messages, right? I'm > not sure that's necessary for just logging in. > > On Mar 26, 9:11 pm, Graeme Foster <[email protected]> wrote: >> 2009/3/26 Chad Etzel <[email protected]> >> >> >> >> > If you don't have a database storing the access tokens or indefinite >> > sessions on your webserver storing them, then the user will have to >> > login everytime. There's no way to get an access token without users >> > going through the OAuth detour. >> > -Chad >> >> In my case I want the client app that is getting and storing its own token >> to be able to hand something to my web service so the user doesn't have to >> authorize twice. >> >> G. >
