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

OAuth implementation for 64Bit windows (no Kerr.Credentials)

Mar 22, 2010 at 10:18 PM


I am building a Worker role within Azure that uses LinqToTwitter. Currently the only authentication I can use is the SimplePassword. This is due to the  DesktopOAuth using Kerr.Credentials which is a 32bit dll. Azure only runs in 64bit, so I have to remove all references to it from the LinqToTwitter project.

I guess the best way forward would be to create a DesktopOAuth that doesn't use the WindowsCredentialsStore, but stores the info in a config file or a db.

Has anyone already attempted this? If not then I will look into producing one, however currently OAuth makes my head hurt and I don't understand most of it.

P.S This is a great project, thanks for the work you have put into it. I'm very impressed.

Mar 23, 2010 at 5:45 AM

Writing a class akin to the DesktopOAuthAuthorization in the LinqToTwitter library is the way to go.  The authorization module is pluggable so you can just add the one you wrote even without recompiling the library. 

The WindowsCredentialStore does not sound like the appropriate place to store credentials when you're on Azure, I agree.  And the DesktopOAuthAuthorization as-is certainly is not appropriate for an Azure worker role as it assumes the currently logged in user is meaningful and it is not in that context.  The WebOAuthAuthorization seems like it would work.  I assume you are using that class already in your WebRole to walk the user through authorization.  Then the worker role can use that same class to send authorized messages to Twitter. 

As you say though, a database seems most appropriate and you'll very likely want to design your database to suit the needs of your app.  Since the db schema is app-specific, you need to write your own implementation of IConsumerTokenManager and pass it into the WebOAuthAuthorization constructor so it knows how your database works rather than storing tokens in memory which will inevitably get cleared periodically, requiring your users to re-authorize the app, which isn't cool.

Does this help steer you in the right direction?

Mar 23, 2010 at 9:08 PM

Thanks Andrew,

Yes this definitely steers me in the right direction (along with your latest blog entry).

The worker role will actually only ever interact with one known twitter account (which I have control of), so I don't need to go through the full OAuth process more than once. Once I have the encrypted string returned (which I can do manually), I presume I can just store this for future use?

So hopefully, my implementation should be quite simple.

Mar 24, 2010 at 4:04 PM

That's not my blog entry, but I'm glad it helped you anyway. :)

Yes, if you just have one Twitter account to access you can hard-code the access token and secret for that just as you might for a username and password.