SingleUserAuthentication and user info

Jun 17, 2012 at 9:38 AM
Edited Jun 17, 2012 at 9:40 AM

Hi there!

I'm working on following scenario. I store authentication tokens for users in my DB.

Then I have a background process that checks for new Twitter messages. For this I use SingleUserAuthentication. I seem to get authorized, since twitterCtx.AuthorizedClient.IsAuthorized returns true, but I am not able to get the screen name of the user whose credentials are being used.

twitterCtx.AuthorizedClient.ScreenName

Returns null...

Any ideas?

Full code:

IOAuthCredentials credentials = new InMemoryCredentials();
            credentials.ConsumerKey = "XXXXXX";
            credentials.ConsumerSecret = "XXXXXXXX";
            credentials.OAuthToken = "XXXXXXXX";
            credentials.AccessToken = "XXXXXXXXX";
            SingleUserAuthorizer auth = new SingleUserAuthorizer { Credentials = credentials };
            twitterCtx = new TwitterContext(auth, "https://api.twitter.com/1/", "https://search.twitter.com/");
Jun 18, 2012 at 11:05 PM

Any ideas?

Coordinator
Jun 19, 2012 at 4:02 AM

Hi Ron,

As its name suggests, SingleUserAuthorizer allows you to perform OAuth authorization for the user who owns the credentials.  The OAuthToken and AccessToken come from your application account.  As the owner of the application, you already know the ScreenName of who is using the program, which is you. 

Additionally, ScreenName will never be filled in for SingleUserAuthorizer because LINQ to Twitter does not make extra calls to Twitter to obtain that information. Since you are already providing all of the credentials, there isn't a need for the extra communication to take place.  The rationale is similar to this post: http://linqtotwitter.codeplex.com/discussions/359116, except that you're using SingleUserAuthorizer.

SingleUserAuthorizer is good for server applications that don't need to authenticate an individual user.  However, if you do need authentication tokens for each user, the best approach is to use one of the other authorizers that do operate on behalf of each individual user.  I'm not sure what type of application you're building, maybe my documentatin on OAuth will help you get going in the right direction: http://linqtotwitter.codeplex.com/wikipage?title=Learning%20to%20use%20OAuth&referringTitle=Securing%20Your%20Applications.

Essentially, you need to keep track of who your users are, make them authenticate the first time, and then re-use their tokens.  Here's a recent discussion on the topic that describes the basic steps to accomplish this: http://linqtotwitter.codeplex.com/discussions/359420.

I know that OAuth is a tough bridge to cross because it's so different than normal username/password authentication.  To help with this, I'm building up a base of documentation and samples over time.  Be sure to check out my documentation at http://linqtotwitter.codeplex.com/wikipage?title=Learning%20to%20use%20OAuth&referringTitle=Securing%20Your%20Applications for the latest info.

Joe

Jun 19, 2012 at 12:07 PM

Hi Joe,

Thanks for your answer. My application stores user credentials in a DB and then launches a background task server side to retrieve new tweets.

What kind of authorizer should I use since my user is not able to use something like PIN or other authentication (since he's not using the app at that moment). Neither does he have to since he already approved my app and his Authorization token is already stored in the DB.

So basically; how do I use the stored credentials to connect to the Twitter service in the background?

Coordinator
Jun 19, 2012 at 4:31 PM

In that case, you have a couple options.  One is to approach Twitter and ask them to use xAuth, which lets you pass the user's Twitter username/password.  Another option might be to add OAuth functionality to the client so that you can obtain the user's credentials and then perform all subsequent work on the server.  These are just a couple ideas, but it sounds like you'll have to do something more creative to make this happen with your architecture.  You're welcome to keep discussing and share ideas.

Joe