Programming

One of the great new standards made possible by OAuth is PortableContacts. Joseph Smarr from Plaxo is the main force behind it together with Chris Messina and others.

Portable Contacts as the name suggests is a standard for allowing one application access to your contact data on another application. The standard is a nice example of a very clean API which supports both JSON and XML.

I was looking around and I couldn’t find a Ruby library for it, so I wrote this simple Portable Contacts Ruby Gem to allow me and others to use it.

It requires OAuth and the Ruby OAuth Gem. If you need to use it with a Rails application use the OAuth Plugin if using straight Ruby use the Ruby Gem. All you need is an AccessToken object and a Portable Contacts URL to get started.

@access_token = ... # instantiate access token
@client = PortableContacts::Client.new "http://www-opensocial.googleusercontent.com/api/people", @access_token

# Get users profile

@profile = @client.me

puts @profile.display_name
=> "Bob Sample"

# Get users contacts
@contacts = @client.all

If you are using the plugin it is very easy to get started accessing Google.

Just install it and configure it. Once you have a GoogleToken for your user:

@google_token=GoogleToken.find_by_user_id @user.id
@client = @google_token.portable_contacts

# Get users profile

@profile = @client.me

puts @profile.display_name
=> "Bob Sample"

# Get users contacts
@contacts = @client.all

As this is the very first version there are likely to be issues, please do submit patches. I would also love to include a PlaxoToken etc for the OAuth Plugin if someone wants to submit one.

Plans

Eventually there will be some sort of auto discovery so you don’t need to provide a Portable Contacts url.

I would also like to add a server component to the gem, making it easy for you to provide portable contacts for your own application.

It has been fairly easy to provide OAuth services in your web application (see How to turn your Rails Site into an OAuth Provider), but to actually consume Twitter, FireEagle, my own Agree2 and other OAuth services has been a fairly manual affair.

There are great gems out there that wrap up the process for the above mentioned services. So it hasn’t been too hard to support one of them. But what to do if you want to support 5 different services today and more in the future?

I knew there should be some generic approach to handle the OAuth authorization process, but had not spent too much time thinking about it until we actually needed to consume external web services for Agree2.

Well I think I’ve cracked it in a a nice Dont Repeat Yourself fashion.

I am really happy to announce a major update to the Rails OAuth Plugin it has been coming over the last week or two with help from Nobukazu Matake.

The plugin is now a gem. Just install it with:

sudo gem install oauth-plugin

For a quick tutorial in how to use it see How to turn your rails site into an OAuth Provider.

New OAuth Consumer generator

The biggest news is the OAuth Consumer generator which should remove any excuses you ever had to not use OAuth when talking to Twitter etc. I will cover this in more the next blog post. For now checkout the README for more.

OAuth 1.0a support

The biggest change on the Provider side is support for OAuth 1.0a. There is also optional backwards compatible support for the insecure OAuth 1.0.

Please read Seth’s Idiot’s Guide to OAuth 1.0a for detailed information on what changed and why.

Nothing has changed on the OAuth 1.0a for existing AccessTokens, but if you need to support clients that only support 1.0 add the following at the bottom of your environment.rb file:

OAUTH_10_SUPPORT = true

HAML support

Both consumer and provider will now create haml view templates. Just use the —haml flag.

Cleanup and easier updates

The original plugin was a really quick proof of concept, with lots of things that really needed cleaning up. I am trying to do that little by little now.

The first step of this is to have the main functionality of the OauthController in a module within the plugin. This allows you to update it easily. We will do the same for the various Token classes as well over the next few releases.

How to upgrade?

As long as you’re using git/svn or whatever the easiest way to upgrade is to run the generator and let it overwrite your existing files. Then use a diff tool to bring any changes you had done into the new code.

If you don’t like the idea of doing that check the README for what should be done. Worst comes to worst create a dummy rails project run the generator and compare files.

Do you need advise or help with implementing OAuth in your Rails application?

I am available as a consultant and would be glad to help your company out. Whether you need help in developing an OAuth strategy or in practical hands on implementation help. Send me an email at [email protected] to let me know what you need help with and I can give you an estimate and my rate.

I suppose I should write a detailed post at some point about this. But here are a couple of notes from working intermittently on Talk.org in the last couple of weeks.

First of all Python is definitely not Ruby. It is very different in many ways. So just accept that and get on with it. Ruby still puts a much larger smile on my face than Python does, but that might be inexperience.

Secondly Django is not at all like rails, even though most python guys seem to claim it is. Pylons seemed much more rails like. However I decided to stick with Django as it’s always good to learn something new.

The best resource I found for getting started was this example project Wuzhere that was demonstrated at Google IO. It is really a great guide to get your head around structuring your project. In particularly coming from Rails, I learnt way more just reading through this code than reading various tutorials on the web. A key piece of code to simplify your life as a rails guy coming over to Django is their view.py class, which acts kind of like a rails render method.

You should use the Django Google App Engine Helper if you are doing Django which is described in this little tutorial. However the approach to laying out your application taken by the Wuzhere developers seemed more logical to me than the approach suggested by the Google App Engine helpers.

Generally speaking I like the AppEngine design. The models are great even if they require you to think a bit differently about the design of your data model. I don’t see a clever way of doing callbacks on the models like with activerecord, but I suspect that something similar would be possible with clever use of Decorators

I would like to say though that while I am still a novice at Django/Python it does seem to me that there are design decisions in both that I’m not quite happy about. Once I’ve worked more with it I’ll see if I still feel that way and can formulate it a bit better.

Featuring Dr Nic, Matz, Evan Phoenix, Kim Dalsgaard and Aslak Helleshøj.

Sorry for the dodgy sound quality. Need to get decent equipment at some point.

Update: I’ve made a higher quality mp4 version of this available here Please let me know if this doesn’t work.