More tweaks, and our experiences with OAuth2 for Facebook and Google
A few changes to Media UK this week: and how our implementation of OAuth2 has been received. What are the gotchas you should be aware of?
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.
James Cridland is the Managing Director of Media UK, and a radio futurologist: a consultant, writer and public speaker who concentrates on the effect that new platforms and technology are having on the radio business.
E-mail James Cridland | Visit James Cridland's website
It’s unfair to place the blame at OAuth2’s feet, whose only concern is authorization and authentication. OAuth2 just verifies the request is from a legitimate, known client, and says nothing about the details of the entity making the request.
The *_name issue is just vendors being vendors and returning similar data with different schemas. Not OAuth2’s business.
I’ve just linked to this posting from Google+; as an update, we support LinkedIn now that they did some technical changes to their service, and we upgraded various bits of ours. They still use bad old OAuth1.0a, but they’ve now added additional bits that make it possible for us to use.