Computers, Web, JavaScript, Stuff…
The OpenID library I'm using for Rosebleed (and other projects, both major and minor) is SimpleOpenID from PHPClasses.org.
The original class did most of what I needed, but I made some minor changes. I've emailed the original contributor to offer my changes back, but until I hear back, I've posted my modified version here:
Comments/feedback always welcome.
I've finally finished up the OpenID signup for Rosebleed. The workflow is what you'd expect – OpenID box on the login form, if the given URL isn't recognized then it redirects to the signup form and prepopulates it with the sreg fields.
I did notice a strange behaviour in OpenID; I'm not yet certain if I missed it in the spec or if it's left to one's judgement (note to self: read the spec again)… Anyway, here's what happens:
– Say I sign up with “roosenmaallen.com”. This site delegates to my ClaimID page, so the openid.identity response is http://openid.claimid.com/silvermoon82, and this is what I actually use to identify the user.
To my thinking, I should be able to log in using “roosenmaallen.com” (since that delegates to my ClaimID), or claimid.com/silvermoon82, or openid.claimid.com/silvermoon82. These URLs all end up at the same identity, so they should be equivalent — and that's how I implemented it on Rosebleed.
I've noticed other OpenID-enabled sites handle this differently. On the OpenID Directory for instance, I first signed up as “claimid.com/silvermoon82”. I've gotten in the habit of logging in using roosenmaallen.com; but when I try that at OpenID Directory, I get an error message that my email address is already registered to my ClaimID URL.
So, barring finding that the spec keeps “equivalent” OpenID URLs separate, I think I'm in the right here; always open to feedback though.
Update [2008-03-19]: I've checked the spec, and as it turns out, I'm actually in the wrong:
So, to use www.example.com as their Identifier, but have Consumers actually verify http://exampleuser.livejournal.com/ with the Identity Provider located at http://www.livejournal.com/openid/server.bml, they'd add the following tags to the HEAD section of the HTML document returned when fetching their Identifier URL.
Now, when a Consumer sees that, it'll talk to http://www.livejournal.com/openid/server.bml and ask if the End User is exampleuser.livejournal.com, never mentioning www.example.com anywhere on the wire.
The main advantage of this is that an End User can keep their Identifier over many years, even as services come and go; they'll just keep changing who they delegate to.
I've been updating the social networking features on [tag]Rosebleed[/tag]. Most of the changes are not immediately visible, but they're nifty:
I've rolled out [tag]microformat[/tag] markup all over the site – user profiles are now [tag]hcard[/tag]-enabled and the friendslist is marked up with [tag]hCard+XFN[/tag].
I also implemented [tag]FOAF[/tag] profiles with autodiscovery, much like that provided by LiveJournal (for a cool FOAF tool, check out the FOAF Explorer).
Still in the works on the SN side is implementing [tag]OpenID[/tag] for logins and order tracking, and hCard, hCard+XFN and FOAF profile-pulling.
Well, I've joined the 21st century and retired my home-rolled site management system.
I've moved the majority of my previous content over to use [tag]WordPress[/tag] 2.2.2 (yes, with proper redirects…), and will be finishing up over the next little while.
The new system has quite a few modernizations: tags, comments, trackback (I've been planning to implement trackbacks for a while, both for here and for Rosebleed; never got around to it), XFN (in the “blogroll” for now, it will grow), and [tag]OpenID[/tag] authentication for comments.
* Note WRT OpenID auth: The OpenID plugin I'm using doesn't seem to play well with [tag]ClaimID[/tag] identities – when you post and authenticate at the same time, it works fine. If you try to post when already logged in, something breaks and it goes into an eternal redirect loop.