OpenID and WordPress Core

This was actually a comment I left on my last post about the v3.3 release of the OpenID plugin. It is a topic that comes up relatively often, and one in which most people are surprised when they hear my stance on it. It’s worthy of a separate discussion for those that are interested, so I’ve pulled it out into a separate post.

I’ve talked with core team about this numerous times… in fact, I spoke at WordCamp Portland and Seattle these last two weeks and talked with Matt about it. For the most part, I actually agree with him that OpenID doesn’t necessarily belong in core, at least not yet.

There’s a lot of thought being given to how WordPress can serve as your “digital hub” on the web. Right now, Automattic is playing in that space in the form of BuddyPress. Now right now, BP allows you to create another social network silo. BP installations don’t talk to each other, and there’s no way to use your account on one BP network to login to a different BP network. I talked with Mark Jaquith this weekend about my desire to see this outward facing functionality. For that, I think OpenID becomes painfully obvious.

I would also like to see this OpenID plugin deployed on WordPress.com to replace the existing plugin. Currently, all WP.com blogs are OpenIDs, but you can’t login or leave comments using an external OpenID. And currently, almost no one uses the existing OpenID provider. Of course, I would argue that this is because they haven’t done a good job of promoting it or adding any new features like SReg or AX. Using my OpenID plugin would greatly enhance the OpenID provider functionality on WP.com, and it would allow people to use OpenID when leaving comments. Some of the changes that are included in 3.3 are actually steps toward cleaning up the plugin so that it is more suitable for deploying on WordPress.com. There’s still more work to be done on this front, but it’s something I intend to continue pursuing.

As for inclusion in WordPress core, I just don’t think we’re there yet. The OpenID plugin is pretty popular, but it is far from having the critical mass that would justify inclusion in core. I am a firm believer that WordPress should by no means try and include every cool feature under the sun in core. It would quickly grow out of control. I do believe, however, that the appropriate hooks should be provided in core to allow any cool feature under the sun to be added as a plugin. The core dev team agrees with me on this, and they’ve been very good about making whatever changes were necessary to allow plugins to provide that functionality. In fact, I overhauled how the authentication system is extended in WordPress 2.8 simply to make things like OpenID and OAuth much easier to implement.

A few other things I’d want to see fixed before considering inclusion in core… the OpenID plugin weighs in at what? almost 900K? Remove the screenshots and readme.txt and you’ve got 700K left. Over 500K of that is the JanRain OpenID library. So size is an issue. Also, the biggest problem that people have with getting the plugin to work is related to their environment. WordPress is known for having a very minimal set of requirements to get it running. I’d really want to track down and fix a lot of these weird environment issues that continue to plague the plugin. Finally, we need a really solid UI, both comment form integration and the admin side. I’m pretty happy with the new comment form integration, but the current admin screens need work. More than anything, there is just a lot of functionality in the plugin and it’s hard to boil it down. Especially when you consider both the OpenID consumer and provider options, both site-wide and per-user.

No related posts.

Posted in identity, technology | Tagged , , | 13 Comments

WordPress OpenID v3.3

I’ve finally gone ahead and released version 3.3 of the WordPress OpenID plugin. This release includes three major sets of changes. First, it drops support for older versions of WordPress… the minimum required version is now 2.8. Trying to maintain backwards compatibility requires a non-trivial amount of effort, and I’d rather spend that time working on new features. It also cleans up the code a fair bit, which I always like. It also drops support for two experimental OpenID extensions known as EAUT and IDIB. EAUT is effectively being replaced by WebFinger, and IDIB never got too much traction. Either could still be added pretty simply by another plugin if people still want them.

Second, this release features a new user interface for the integrating OpenID into the WordPress comment form. Instead of simply advertising OpenID support on the “Website” field, and always attempting OpenID authentication, the plugin now detects OpenID support for a URL, and gives the user the option to authenticate the comment. This provides a cleaner, less obtrusive interface that should work on most all themes. It also gives the user the option to not authentication that particular comment if they don’t want (particularly useful if you’re on a mobile device or in a hurry and don’t want to mess with OpenID). Feel free to try it out on this post if want. You really don’t even have to submit the comment to see it in action… just enter a valid OpenID URL for the website field, and move focus somewhere else (ie, click in the comment box like you’re going to type a comment). There is currently no option to revert to the old style of comment form integration, so hopefully folks will like this new UI. If you really don’t like it, you always have the option of turning off comment form integration and modifying your theme to your heart’s content.

Finally, this release includes a lot of minor bug fixes that people have been complaining about (sorry it took so long). I’m sure I didn’t get to all of them, so please let me know what I missed, and I’ll try to do more regular minor releases with these smaller fixes.

I’ll additionally note that working on WordPress plugins is no longer part of my day job, so I currently work on them rather sporadically as I have time. The changes in this release have been developed a few hours at a time over the last couple of months. I’ve been running trunk here on my site for quite some time and haven’t had problems, but you never know. Please use the DiSo issue tracker to report any new bugs, or to remind me of existing tickets that are still not fixed in this release.

No related posts.

Posted in identity, technology | Tagged , , | 15 Comments

iTunes 9, now with more WebKit

As John Gruber predicted yesterday, iTunes 9 certainly uses WebKit much more than the last version. I used wireshark to do a packet trace when I clicked on the Rock Music section. Sure enough, if you gunzip the response, it is effectively standard HTML (though they do declare a custom XML namespace for everything). It looks like this new HTML based format is triggered by the request header:

X-Apple-Store-Front: 143441-1,5

For example, the following simple curl command will retrieve this Rock page:

curl -H "X-Apple-Store-Front: 143441-1,5" \

http://ax.itunes.apple.com/WebObjects/MZStore.woa/wa/viewGrouping?id=24

To further verify that iTunes was doing little more than rendering the result with WebKit, I went through the response HTML, fixed a couple of URLs, and got this result — exactly what you see in iTunes 9. Of course, the “Quick View” for each album doesn’t work, but you can see how it is all pieced together.

No related posts.

Posted in technology | 22 Comments

A New Kind of OpenID Proxy

After writing last weeks post on directed identity, I really got to thinking on the topic a little more. One of the things that has always bothered me about the prospect of sites requiring the use of directed identity, is that it means I can no longer use my self-hosted OpenID to login. Currently, I have the WordPress OpenID plugin installed, and I use it as my sole OpenID provider. While the plugin does support identifier select (mainly for blogs which have multiple authors), it does not support directed identity. But even if it did, it wouldn’t make much sense… an OpenID URL of the form “http://willnorris.com/openid/9eb4d59c1d488a4” doesn’t do a very good job of masking who it belongs to. No matter how opaque the path, the URL is still rooted at the authority “willnorris.com” which means it can belong to only one person — me.

So what am I to do? The most obvious answer is to simply use one of the larger hosted OpenID providers that support such a feature, like Google. But I have some real problems with that, both philosophically and practically. Fortunately, I think I may also have a better solution.

Read More »

No related posts.

Posted in identity, technology | Tagged , , , | 14 Comments

Best Practices with Directed Identity

Given the current discussion happening right now around federal website cookie policies, and the good response I got from my last post, I wanted to continue talking about directed identity a little bit. In this post, I want to talk about how directed identity has actually been implemented in projects I’ve been involved with, and what lessons can be learned from that.

Read More »

No related posts.

Posted in identity, technology | Tagged , , , | 2 Comments