This project has moved and is read-only. For the latest updates, please go here.

Using dotnotopenauth to authenticate

Mar 4, 2011 at 1:55 PM

In my project I allready have dotnetopenauth set up for authentication and after a successfull twitter login, I store the oauth_token, the access_token and the the access_tokensecret in a database.

I'm now trying to send a tweet using the following code:



IOAuthCredentials credentials = new SessionStateCredentials();
credentials.ConsumerKey = Busker.MVC.Properties.Settings.Default.TwitterConsumerKey;
credentials.ConsumerSecret = Busker.MVC.Properties.Settings.Default.TwitterConsumerSecret;

// for simplicity and debugging I'm storing the tokens in the session for the moment
string accessToken = Session["AccessToken"].ToString();
string oauthToken = Session["OAuthToken"].ToString();
credentials.OAuthToken = oauthToken;
credentials.AccessToken = accessToken;

MvcAuthorizer  auth = new MvcAuthorizer
    Credentials = credentials


TwitterContext twitterCtx = new TwitterContext(auth);
if (auth.IsAuthorized == true)
    var tree = true;

twitterCtx.UpdateStatus("Hello world!");


When the last line is called, the web app simply hangs (doing nothing as far as i can see) and can only be revived with an IISReset

Is this the correct way of passing tokens to linq to twitter?

Mar 4, 2011 at 7:58 PM

Hi AyKarsi,

I haven't run your code to try to reproduce what you're seeing.  However,  just looking at your code, I see a couple things that might help. 

First, I noticed that you're already loading your credentials, AccessToken and OAuthToken.  In this case, you don't need to call CompleteAuthorization because you have everything you need.  The only time you need to call CompleteAuthorization is for a brand new user, who you don't have credentials for, and where you've already called BeginAuthorization.

Second, after you call BeginAuthorization, Twitter redirects back to your callback URL, which is often the same page (at least it is in my demo), passing the verifier and oauth token.  When this redirect happens, you would then call CompleteAuthorization.  But, here's the trick and what I think is causing your problem, you must pass in the Request Url, "Request.Url" because it contains the verifier and oauth token that Twitter sent and LINQ to Twitter will extract those values from the URL and populate the *Authorizer.  So, after a CompleteAuthorization call, you'll have the credentials, along with User ID and Screen Name, on the *Authorizer that you can grab and store in the DB for that user.  I think you should be getting an ArgumentException because of passing null to CompleteAuthorization, which you can check by wrapping the value in a try/catch or some other error handling routine.

Hope this helps,


Mar 6, 2011 at 4:15 AM

BTW, That isn't DotNetOpenAuth.  The OAuth you're seeing is native to LINQ to Twitter.


Mar 7, 2011 at 7:00 AM

Hi Joe,

thank for the feedback:

1. I've tried all varitions of setting the url and tokens which I got via dotnetopenauth. The only notable change in behaviour I could achive was passing in the url twitter returns to after authentication (the url which cotains the oauth and verify token). When I pass this one to the auth.CompleteAuthorization Method, it immediatley gives me a 401. In all the other cases the code hangs on last line (twitterCtx.UpdateStats(string)) and needs the IISRESET to be revived. The behaviour is also the same when I comment out the auth.CompleteAuthoirzation() line..

2. Regarding you second comment, saying linq2twitter isn't dotnetopenauth: I read a post on SO from Andrew Arnott saying linq2twitter uses dotnetopenauth. ( Are maybe the tokens I'm getting via dotentopenauth "incompatible" with your implemenation?



Mar 7, 2011 at 9:36 AM


Have you tried the MVC demo in the downloadable source code?  That's working for me and if it works for you, we'll be closer to a solution. 

BTW, I just released a new version of LINQ to Twitter today, so you'll want to grab the latest.  There are downloads both source and binary.  The MVC demo, in the LinqToTwitterMvcDemo project, is in the source download.  This was the first release that I separated normal binaries from Silverlight binaries.  Make sure you download the normal (non-Silverlight) binaries.  BTW, you might want to double-check to make sure you aren't accidentally trying to use the Silverlight binaries, named LinqToTwitterAg.dll.  You should be using LinqToTwitter.dll.  This will also eliminate the possibility of you finding a bug that's already been fixed.

If you want to send me some code, you can use the CodePlex contact form and send me your email address.  Please boil the code down to only the smallest possible sample that reproduces the problem for you. (It saves a lot of time).

OAuth in LINQ to Twitter used to be based on DotNetOpenAuth, which is a fantastic library.  However, I replaced it so I could support additional platforms like Silverlight, Mono, etc.


Mar 7, 2011 at 2:23 PM


the MVC demo works fine for me.

My current assumpution is, is that dotnetopenauth generates a different access token to your implementation. (Wild assumption because I've absolutely no idea what is happening on a lower level. Maybe its because the authorisation urls are different; same webapp and twitter keys though ).

Because I've realized that I need a sepearation of using twitter for authentication and using twitter to update the status. I think I will change my setup to the following:

- Use dotnetopenauth for application authentication

- Use linq2twitter for updating twitter status. This will require a second access token, which I will need to persist in the db.
(See for more background info)


P.S. I was wondering what the Ag stands for; go it now :)

Mar 7, 2011 at 6:44 PM


I read that and it's very interesting.  I'll have to do some more research and see if I can do something about it in LINQ to Twitter.  At least I should add the option to let you specify the read-only status, since that seems to be supported by Twitter.

Thanks for following up and sharing what you learned.


Apr 7, 2011 at 6:53 PM

Has anyone been able to verify that dotnetopenauth is truly generating a different access token?