Hi Wallace, http://www.Twollo.com does something similar to what you are describing (it hosted on the Google App Engine). You can store the users oAuth token secret, access token (and request token if you don't have the access token) and then use these at a later date to send authenticated requests to Twitter. The good thing is that once you have the access token it is unlikely to expire (unlike a users password) unless the user revokes access to your application.
Admittedly there is some user interaction, but it is only at the start of the process, much like the current process of asking for a users username and password. Once it is all done it is easy to make authenticated requests to Twitter without any user intervention. This thread is mainly about the changes that were made to support desktop applications, but again, once the access token has been received the same applies as mentioned earlier. Paul 2009/6/6 Wallace <[email protected]> > > I wanted to follow up on this. Admittedly, I'm a newb with oauth. > I'm currently working on an application that uses MS's cloud computing > environment Azure. I'm using this to schedule tweets in the future. > Azure has a worker role which is an application that a web user never > directly works against. The worker role is being used to post updates > to a user's stream. Right now, I am using basic auth, but I would > like to move to oauth. My current design has the user storing > twitterids and passwords in a table. The user interacts over the web > with the webrole and then the worker role handles the posting. > > It looks to me, given a VERY limited knowledge of oauth, that its > designed with user interaction in mind. Does that sound correct? > > Wally >
