Twitter update access with OAuth and DotNetOpenAuth

Question

I'm trying to use OAuth with .NET (DotNetOpenAuth) to send updates to a Twitter account via a web application. I understand the basic workflow of OAuth and Twitter.

Where I'm confused if is it useful in a server web application? I don't want any user interaction. But how it seems after an application start, the request token needs to be recreated and also an access token. This involves user interaction.

What is the correct workflow for my case? Storing the request token or access token in config file? Or the easist way, using HTTP basic authentication?

Thanks

Answer 1

If I understand you correctly your application will not be interacting with Twitter on behalf of your users but will be acting as the Twitter account for your application.

In this case there are 2 main factors to consider.

1) Do you want "from API" attached to each status as will be if you use basic auth or your applications name will happen if you use OAuth. 2) Do you want to put in the extra effort to implement OAuth.

If you decide to go with OAuth you would store your apps consumer key/secret and the accounts access token in configuration just like you would store the accounts screenname/password.

Answer 2

Your "request token needs to be recreated" phrase suggests you might be running into the problem where every time your user visits you need to re-authorize to Twitter, and perhaps you're looking for a way to access the user's Twitter account while he's not at your web site, and how can you do this when their token isn't fresh from being re-authorized. Is that right?

If so, the user isn't supposed to have to re-authorize Twitter every time they visit your site. The token is supposed to last a long time, which would also allow your site to access their Twitter account when they are not directly interacting with your web site. The problem may be that you haven't implemented the IConsumerTokenManager interface, but are instead using the default InMemoryTokenManager, which is for sample use only, since this memory-only token manager loses tokens every time the web app is restarted. Your own implementation of this simple interface should store and read the tokens out of some persistent storage such as a database.