11 Twitter OAuth Tips and Tricks

If you are building a Twitter app then at some point you are going to be faced with integrating OAuth. This article summarizes my top eleven time saving tips-n-tricks. If it helps you out or if you have other tips and tricks please share your comments and ideas.

Okay so what’s OAuth? Bottom line, it’s an open protocol that gives your app special access on a user’s behalf without having to deal with storing their user name and password.  So, rather than usernames and passwords, you are going to be handling tokens. You may already be thinking whoa! Aren’t I just trading one security problem with another? Sure, there are security issues with OAuth and if you search on the internet you’ll find plenty of rants about them. The bottom line is that tokens, like usernames and passwords, can also be intercepted and potentially used to access someone’s account. I address that issue below. But, if you want to build a Twitter app you are going to have to figure out the best way to implement OAuth, end of story.

Read on and let me know what you think:

  1. Before trying to build an Oauth library from scratch, check out ones that have already been built. It will save you a ton of time. For starters, check out this page: http://dev.twitter.com/pages/oauth_libraries
  2. Read Twitter’s article on “Authenticating requests with OAuth.”  It’s not very long and I thought it provided a lot of very helpful information.
  3. Register your app at http://dev.twitter.com. If you don’t register, then OAuth transactions will not work.
  4. When you register your app with Twitter, on the settings page make sure the Callback URL points to an actual, functioning, domain name whether you will use it or not. It should look something like this: http://mydomainname.com/oauth.php. You’ll quickly find out you can’t specify localhost, or if you do it doesn’t work. More on that in a minute.
  5. If you are building a web-based Twitter app you will need to run all your requests through a proxy. In your proxy, you can override Twitter’s Callback URL parameter by setting your signature’s oauth_callback parameter (see reference section below for more info). This is especially useful for prototyping and testing when you want to use something like http://localhost/oauth/confirm.php. If don’t override the oauth_callback parameter, then you can’t use localhost for testing.
  6. Never ever store your Twitter consumer key or consumer secret on the client. Client apps can be de-compiled and then your secret won’t be so secret anymore.  Store these on your proxy.
  7. Always encrypt oauth_token and oauth_token_secret when storing them on a client app.
  8. Use HTTPS for all oauth transactions that require a user name and password. Otherwise, this information can easily be intercepted, especially over public wi-fi.
  9. Twitter avatar images also require the use of a proxy. Twitter has implemented fully restrictive cross-domain polices so that web browsers can’t access these images directly.  If you are getting cross-domain errors then check out this post for hints. 
  10. Twitter’s OAuth access tokens don’t expire, although for security reasons it’s a good idea to refresh them on a regular basis. Just remember, refreshing them does involve forcing the user to re-login with Twitter.
  11. Twitter has a very handy online tool, called the Twurl Console, for testing out API calls via HTTP and seeing the headers and results without having to write any code. Once you have registered your application, you can find the tool here: http://dev.twitter.com/console You can also use something like Firebug or Fiddler, but they don’t have all the twitter API commands built into a pulldown list!

Just a few references:

To see a working OAuth sample app along with Flex source code and PHP proxy go here.

Oauth 1 Website: http://oauth.net/

Latest OAuth spec RFC5849: http://tools.ietf.org/html/rfc5849

Reference to the OAuth call_back parameter: See section 2.1 of RFC5849 above. To see the call_back implemention in the code sample above, look in the file EpiOAuth.php.

Hello world – FAIL! A lesson in blog hosting.

Maybe it’s fate, but it’s certainly appropriate with respect to the title of this blog, that in less than 30 minutes after spinning up the blog for the first time it crashed..hard. Now before you get too judgmental about my software choices, I’m going to place the blame on myself and my hosting provider for selling me a worthless, bare-bones blog hosting package. Yes, I did my homework and even solicited advice from blog veterans. Sure, I could have spent endless additional hours digging into it further and then making the perfect choice. But, I reached a point where I chose to jump.

After trying to upload a new theme template and the system crashed, my conversation with tech support went something like this:

Me: My system just crashed, how do I get access to my blog’s log files to see what happened?
Tech Support: You cannot sir, that requires a different hosting package.
Me: Can I change the write permissions on any of directories, it seems like I can’t change anything in the template editor?
Tech Support: Again, sir, sorry but that requires a different hosting package.
Me: Your documentation says you can modify themes, but the editor says I need to activate write permissions?
Tech Support: Yes, you can only change certain things.  We don’t support WordPress. You’ll have to contact them directly.
…and on my conversation went. Yes, I ended up upgrading my hosting package.

Two Important Questions Before Your Purchase Blog Hosting

Now I know that two simple questions could have saved a few hours of work. Sure there’s many more and I hope you can share with me. But these were the ones that stopped my progress dead. So, here they are:

  1. Will I be able to modify the code in my themes, widgets and plug-ins via an online editor?
  2. Does this blog hosting package give me access to log files for troubleshooting?

If you want more than the very basic blog control, for example if you think you may simply want to tweak how something looks in a theme template, then tech support needs to answer an emphatic “yes” to both of these questions for your hosting package. If they don’t, then keep researching for hosting options that will fit your needs.