The peril of standards
At first sight, it should be a simple problem – write a web services backend to a provided HTML5 frontend to handle OAuth logins to a couple of different services, intelligently storing the authentication information and allowing posting to those services via the integrated frontend.
Oh, $DEITY was I wrong.
Firstly, OAuth has a kind of triple handshake thing going on that means that I have to reengineer the front end to load the required login pages and then handle the callback. Okay, that’s fine. Doable, if nothing else.
Then turns out that the thing that’s passed back isn’t the actual string that needs to be stored. Okay, background call to get the actual string, that’ll be fine.
Then, apparently those strings expire. Oops, nobody mentioned that. So, when they’re not valid any more, you have to pass back the original string and get a new one. But you can’t just use that, that would be silly, so both have to get stored.
Is it any wonder I’m pulling my hair out right now?
I sometimes wonder whether the purpose of an open standard is just to make it so everything is equally annoying. Which is helpful, I’ll grant them that.
The problem arises when the web frameworks that will eventually have to function within that system either aren’t set up to handle them at all or try to do too much for you.
For example, Grails has a beautiful OAuth plugin, which I’m sure works great for websites written in Grails, but which continually throws weird redirects and stuff around when I try and modify it. Cue several hours of rolling my own. Several hours I don’t have, I should add.
Ah, well – at least I don’t have to write separate handlers for YouTube, Facebook and Twitter. If only flickr would get on the OAuth bandwagon, I’d be a happy man!