Assuming Twitter keeps to a long/no expiration model for the OAuth tokens (as I understand it, it currently is set to not expire in the beta), or better yet, have a choice method for how long the token will last, for users accessing a site that accesses twitter, have a short expiration (an hour or a day), but have the option to create a token for client side applications that don't expire, then there shouldn't be a problem. You have your client program check to see if your token is valid, if it is not, spit out the url to get a new token, then you just paste your token back into your app's information and it's good for another 6 months or forever or whatever. It should even be possible to have your script get the token for you, for your own purposes if you store your login information, you can have your script access the url, get the token, and save it.
There should be no real reason to save end user's login information, they should grant you access for the time periods that they access the site, it's much more secure that way overall, and if Twitter keeps to a long expiration model, saving those tokens to act for a period of time should be fine. On Mon, Feb 9, 2009 at 2:03 PM, funkatron <[email protected]> wrote: > > I still maintain that this works fine for knowledgeable web dev folks > (who seem to be the people who get excited about OAuth), but *will* > confuse users who don't understand the tech involved, and/or aren't > comfortable jumping between apps. In addition, the process becomes > even more problematic with apps that don't run on a modern windowing > platform (like CLIs, mobile devices, and the like). > > If you have hard numbers from usability studies that prove my > suspicions unfounded, that would be *great*. I'd love to be wrong. > > -- > Ed Finkler > http://funkatron.com > AIM: funka7ron > ICQ: 3922133 > Skype: funka7ron > > > > > On Feb 9, 4:12 pm, Blaine Cook <[email protected]> wrote: > > OAuth was designed with explicit desktop application support in mind. > > To see how it works in practice, try using a desktop Flickr Uploader > > or iMovie's YouTube integration. > > > > Normally your app will open a browser window (all modern environments > > do this seamlessly) and ask the user to authorize the application. > > Once they've done that, they should be told to go back to the > > application (close the browser window) and continue the setup process > > (usually by just clicking "Continue" or OK so that the desktop app > > knows that it's OK to exchange the request token for the access > > token). > > > > b. >
