OpenID and Email Portability

Now that we’ve got OpenID running as a login/registration option on The Conversations Network, I’m concerned about a particular weakness. Maybe the Identity Gurus can help me out.

I’ve taken the advice of others and allowed registered members to attach multiple OpenIDs to their CN logins. It’s very convenient. For example, I can login with http://dkaye.myopenid.com, http://rds.com (a delegated OpenID) or a variety of others. But this isn’t solving an important problem that I think it should. What happens when I, as an OpenID owner, change my email address? I’d like to just change it in one place (my OpenID provider’s site) and have that change automatically propagate to the sites where I use my OpenID the next time I log into them (if not before). The service providers allow me to change my email address and that address is transmitted to the sites when I use my OpenID.

The problem is that because we receive those email addresses from potentially multiple providers, they can be different. And when we receive an email address as part of an OpenID authentication transaction, we have no idea whether we’re supposed to change our database to reflect that new email address or not. Bottom line: We have no choice but to ignore the email address we receive except the very first time when we can use it as the default for a registration-form field.

I thought OpenId credentials were like the old wallet concept, but how is a web site supposed to deal with an individual who supplies multiple wallets? Am I missing something here?

OpenId Adventures

I’ve spent the last three days trying to implement OpenID for The Conversations Network’s web sites. I’m familiar with the concepts and protocols, so I figured it wouldn’t take much effort. I guess that’s what I get for being so self-confident. I still don’t have a solution to the current snag. Maybe someone else knows a workaround or at least some search engine will find this so others can avoid the traps I’ve fallen into.

All our sites are built on PHP5. I develop on OS X, check my code into Subversion, then checkout onto our live servers running RHEL. I chose the OpenID Enabled library. It’s really the only choice as far as I know.

I don’t know whether it’s a bug, poor documentation, or just our peculiar architecture, but there was an incompatibility between OpenID Enabled and my code that took about 12 hours to find. (If the URL of your response receiver includes a query string, you’ll have some extra work to do.) I finally got past that, coded new pages for login, registration and managing multiple OpenIDs for a user, and checked it into svn. I installed the library on the RHEL server and updated the code there. Didn’t work.

It turns out that the OpenID Enabled library needs an XML parser, either domxml (which is no longer available) or the newer/better DOM, which comes with the PHP 5 core code. But we use yum, and the yummy version of PHP5 was built with the –disable-dom option. So no XML parser and hence no OpenID. Aargh!

Sysadmin Tim doesn’t want to mess with another PHP5 build, and after years of working with him — and sometimes ignoring his advice — I’ve learned he’s always right. Surely, replacing our PHP5 (or even rebuilding it) would likely break something else. So I’m stuck until I can either find another OpenID library that doesn’t require the DOM XML parser, or some replacement for that parser. Too bad. OpenID is sort of cool.

Update: Problem solved. Just ran “%yum install php-xml” and restarted Apache. We now have OpenId across all The Conversations Network’s web sites.

Return of Reality Break

Podcasting pioneer and friend, Dave Slusher, is reviving his Reality Break radio series as a podcast. Dave honed his interviewing skills well before the advent of podcasting, and I’ve always appreciated his research and preparedness, which help make his programs a cut above the rest. For a while, Dave hosted the Voices in Your Head series on IT Conversations. The majority of Dave’s interviews are with authors, most notably those of science fiction.

The Verio Vultures

The Conversations Network and IT Conversations have running on servers at The Planet for many years, and we’ve been very happy with the performance and support. Apparently — I know nothing about it — there was a fire in one of their data centers or something. In any case, it certainly hasn’t affected us. But the folks at competitor Verio smell blood. I’ve received three phone calls within the past hour, each one for a different person who doesn’t really work at this location such as Paul and Leah. The callers are trying to scare us into switching. However, the number they’re calling is on the national do-not-call list, and since I have no relationship with Verio, they shouldn’t be calling us. And the substance of teh calls is quite sleazy. Shame on you, Verio.

Campaign Flash Ads from AdSense

I was surprised to see a 300×250 animated/video Flash ad for John McCain appear on our ’08 Conversations channel on this page that isn’t particularly flattering to McCain. I was even more surprised, however, when I noticed that there’s no typical “Ads by Google” tag. Without it, one might assume that The Conversations Network accepted advertising directly from the McCain campaign, which is not the case. Not sure I like this. I wonder if there’s a way to disable political ads on our AdSense account. I don’t mind running such ads when we’re not a party to their selection, but this could send the wrong message. Might also be a problem with our 501(c)(3) status.