More tweaks, and our experiences with OAuth2 for Facebook and Google

For Media UK discussions, a small style overview means it's easier to scan the topic list, and you'll now spot peoples' faces next to their posts. (We're getting those from Facebook or Google+ when you log in).

Our Twitter lists now look beautiful whatever device you're reading, with larger avatars and a more consistent look with the rest of Media UK.

We've added full support for Textile within our discussion system and our job adverts; and RAJAR graphs now resize properly depending on your device's width, too. We've also stopped articles (like this one) from being in columns if they're shorter than a predefined limit.

-

We've also learnt a fair amount about logging in using Google and Facebook over the past few weeks, which we thought might be interesting to share.

Unlike original OAuth, OAuth2 is a very simple and straightforward tool to use: instead of incorporating a third party code library, it was pretty easy to roll our own OAuth2 login code. The entire login code is less than twenty lines of PHP.

Although both Google and Facebook use the same OAuth2 specification, both give you a unique set of issues to handle. As an example, what Facebook calls a first_name and last_name, Google calls a given_name and a family_name. We found it made most sense to write a login script for each service, to cope with the inconsistencies from each provider.

Pictures are another area for inconsistency. Google has a specific field for a user's picture (which may or may not be present), while Facebook simply uses the user's id inside a URL construction. Incidentally, in line with our policy of avoiding third-party resources where we can avoid it, we copy a user's picture over to our own servers whenever someone logs in: this has the added advantage that to display a user image is a consistent URL. This adds a small delay when logging in, as our systems retrieve the image and then upload it to Amazon S3's servers: we should probably add this to a queue at some stage. Images from both services are differing sizes, too: currently we don't resize those images, but it's likely that a future login script will probably resize the image before storing it, once we've confident we know whether we need a smaller image.

One gotcha to look out for is that, when using Google, it's perfectly valid - for a small subset of users - for a valid login to return no information whatsoever about a user except for an email address - so you end up with a blank name, for example. This is in the (fairly rare) example of a legacy Google Account that a) was created without an accompanying Gmail account, and b) has no Google Profile. We've elected to reject these login attempts, and request that people create a Google Profile first before logging in.

We've also caught at least one instance of a user logging in to Facebook, but returning no information at all other than a valid access token. We're not sure what's going on here, but we're now rejecting user logins that don't have a first_name set.

What we have quickly discovered is that Google/Facebook logins work very well for many of our users, and has made commenting in our discussion system, particularly, a quick experience.

We'd dearly like to add a LinkedIn OAuth2 account login, but unfortunately, LinkedIn only uses the original OAuth, which is simply too complex for us to currently implement. In late 2010 they added their own JavaScript implementation based on OAuth2, and it would be very much welcomed if they finished their OAuth2 work. In our limited research, those who don't have Facebook or Google accounts do have a LinkedIn one, and for business users it's a good system to use. C'mon, LinkedIn, we're waiting!