I’ve been considering consolidating these down into a single site, putting my activity stream on the front page and my blog under a sub-directory. Of course I’ll setup proper redirects and such so that no links will be broken. I can also update my OpenID at all of the services I use, so that’s not really a problem. .com as a TLD is certainly more familiar with people, but the .name is technically the “correct” TLD for individuals. So now I’m relying on others to give me input… which domain should I use?

• OpenID Provider - Specific user roles can be given the capability of using the built-in OpenID provider, turning their author posts URL into a valid OpenID which can be used to login to other sites. This includes support for OpenID 1.0 and 2.0 as well as Simple Registration 1.0, with hooks to add other OpenID extensions.
• OpenID Delegation - Users authorized to use the built-in provider can optionally choose to delegate their OpenID to another provider instead.
• EAUT Mapper - Support for the draft Email Address to URL Transformation protocol. If you use an email address at the domain of your WordPress blog, you can now use use that email address to login wherever EAUT is supported.
• Extensibility - the plugin now has a number of public functions and hooks that other plugins can use to integrate with or extend the OpenID plugin. These are all documented here.

It’s worth mentioning that pretty much all of the new features require that you also have the XRDS-Simple plugin installed. There are also a number of other changes in regards to simplifying and stabilizing the plugin, than can be read about here.

Choosing the right hostname

Part of my custom setup is that I have a whole slew of bogus hostnames pointing to localhost, which Apache then dynamically maps to the correct document root. For the most part, I just drop the TLD from the actual hostname… so http://willnorris/ is my locally hosted development site for this blog http://willnorris.com/, and http://will.norris/ is my development site for http://will.norris.name/. I also keep a handful of WordPress versions running locally, so I can test plugins in those different environments — http://wordpress-2.3/, http://wordpress-2.5/, etc. When I began to setup my WordPress MU (and BuddyPress) instance, I used the site http://wpmu/. The installation went fine, but when I tried to login it failed every time. Given that this same setup worked fine with single-user WordPress, I was quite confused. I quickly realized though, that the authentication cookies were never being set for WPMU… in fact no cookies were.

The difference between the two versions of WordPress is the value of COOKIE_DOMAIN which is passed to setcookie(). Both flavors of WordPress allow you to define this constant in wp-config.php, but they differ in what happens if it is not defined there. WordPress sets it to the boolean false, whereas WordPress MU sets it to '.'.$current_site->domain. This results in a different Set-Cookie HTTP header between the two. Take for example the wordpress_test_cookie cookie. WordPress sends the response header

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/

whereas WordPress MU sends the response header

Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/; domain=.wpmu

The difference of course is the domain=.wpmu there on the end. In a production environment, this wouldn’t make a bit of difference. But because I’m using fake hostnames in a development environment, this makes all the difference in the world. You see, the HTTP Cookie Spec (Section 4.3.2 Rejecting Cookies) requires that the domain attribute includes an “embedded dot”. This is a security feature that prevents a site from setting a cookie on a top level domain like “.com”. Since single-user WordPress wasn’t specifying a domain attribute, it didn’t have any problem setting the cookie. Because my hostname wpmu doesn’t contain an embedded dot, the browser was properly rejecting the cookies, preventing me from being able to login. So our solution here was to use the site http://wp.mu/ (note the added dot in the middle) for hosting our WordPress MU development site.

Sending Mail

The other main problem I had with WordPress MU was that none of the notification emails were being delivered. This was actually a problem with single-user WordPress as well, but it didn’t matter as much then. Now I’m needing to test the account sign-up process a bit more, and so I need the activation emails that are being sent out. It’s been a long time since I’ve administered an email server, so I won’t embarrass myself by trying to explain what the problem was (something along the lines of my ISP’s SMTP server not liking what mail() was sending) . I was however able to fix it by writing a very simple plugin, Development Mailer, that changes a few configuration options of PHPMailer. This works for me on Mac OS X (Leopard), but I make no guarantees for anyone else. Keep in mind that his plugin should only ever be needed for a development environment… if you’re unable to send notification emails from your production blog, then you’ve got other problems.

• Initiate script from Quicksilver
• Grab URL from the front-most window in Safari
• Submit URL to URL shortening service (previously xrl.us, but more recently bit.ly)
• Copy shortened URL to system clipboard (for pasting into Twitterific)
• Notify of process completion via Growl

I’ve tried a number of different workflows including bookmarklets and the like, but this one works best for me (read: I honestly don’t care what you think of this flow or what you do instead… this is what I prefer).

Recently I discovered a new URL shortening service, tr.im, and decided to give them a try. However, unlike most services, tr.im doesn’t simply return the shortened URL. Instead it returns either an XML or JSON structure that includes the shortened URL along with some other data. Quickly realizing that AppleScript doesn’t handle JSON very well, I decided that this would be a good opportunity to start learning Python. The result was the following Python script:

http://willnorris.com/svn/homedir/packages/tools/local/bin/trimURL

It follows the same flow as mentioned above, making use of a couple of Python modules (which are required for running this script): simplejson and appscript. Put this script in a directory that Quicksilver scans (I think the Terminal Quicksilver plugin is also required). If you want to authenticate to tr.im, add your username and password to your ~/.netrc file. I also set the script’s file icon to be the tr.im icon, so it will be displayed in the Growl notification.

• Don’t use OpenID at all
• Use the local OpenID provider built in to the plugin
• Delegate to another OpenID

If a the local OpenID provider is used, it also supports transmitting sreg attributes pulled from the user’s WordPress profile and the DiSo Profiles plugin, if it’s installed. The user can update this data before releasing it to the relying party, but those changes aren’t currently stored. In addition, trust decisions are recorded and stored for the user, and can be modified from their config page at any time.

If a user chooses to delegate to another OpenID, they need only provide the delegate OpenID itself. All server configuration and supported extensions from that provider are discovered and published in the local XRDS document. Of course this data will have to be cached and probably updated on some interval, but it makes setting up delegation a breeze.

Server Modes

Remember that every user’s OpenID is their author posts URL. So what about the home URL for the blog itself? Well, the OpenID server can operate in two basic modes: multi-user and blog-owner… perhaps not the best names, but they’ll work for now.

In multi-user, the default configuration, the server supports a feature in OpenID 2.0 called OpenID Provider driven identifier selection. What this means is that ANY user on that blog can enter the home URL as their OpenID, and the OpenID provider itself will make sure that the correct identifier is returned to the relying party. The final identifier will still be something like http://example.com/author/admin/, but the user only needs to enter example.com at a relying party. If you’ve used ever used Yahoo’s OpenID provider, then you’ve probably seen how this works.

I suspect the more common mode will be blog-owner, which is appropriate for personal blogs. Even if there are multiple users in the system, the blog is basically owned by one individual and it makes sense for that individual to use the blog home URL as their OpenID. This mode is activated by selecting a “Blog Owner” on the main plugin configuration page. Once set, this user’s personal OpenID configuration (whether turned off, using the local provider, or delegated to another OpenID) will be used at the blog home URL. Other user’s on the blog could still use their OpenIDs, but they would need to type in the full URL each time… they just lose the convenience of being able to use the blog home URL.

For security, once a blog owner is set, no other user can update the setting. The blog owner can set someone else as the new blog owner (a push mechanism), but no-one can take ownership away (a pull mechanism). Additionally, if a multi-user blog wants to ensure no-one is ever set as the blog owner, they can add the following to their wp-config.php file:

define("OPENID_DISALLOW_OWNER", 1);

What’s left to do

The main outstanding work to be done before release is the user interface. You’ll notice that the user’s configuration screen (where they manage their external OpenIDs, OpenID Provider preference, and Trusted Sites) is a bit confusing if you’re not to familiar with OpenID. The current layout was done simply for convenience while developing the OpenID Provider, and will be overhauled to some degree before the release.

I’m also not too sure about compatibility with older versions of PHP and WordPress. I’ve been developing using PHP 5.2.6, MySQL 5.0.51, and WordPress 2.6.1. I do intend to remain as backwards compatible on these as possible (within reason), but make no guarantees for the current development code. I’ll also be working to make everything compatible with WordPressMU and BuddyPress. For now, I just wanted to get the code out there, and get people playing with it a little bit.

Simplified Database Structure

Version 1.0 of wp-openid added four new database tables and overloaded one of the comment table fields in a weird way. Version 2.0 required only three of those four tables and added one column to the comment table to eliminate the overloaded field. The current development version doesn’t add any columns or overload fields of existing tables, and adds only one new table of its own, which I’m still hoping to eliminate.

The two removed tables were used to store OpenID associations and nonces, both of which are temporary data necessary to make OpenID security actually work. Instead of using these tables, I’ve opted to use an updated version of the OpenID store used in Simon Willison’s mu-open-id plugin which uses the WordPress options table to store this data. I’ve updated his store to use the latest php-openid APIs as well as to reduce the potential for race conditions.

I’ve removed the column from the comments table that was tracking which comments were left using OpenIDs, and am instead storing this in the postmeta table for the post the comment is associated with. It would certainly be preferable to have a commentmeta table, but I like this better than the previous solution.

The one remaining table is the identity table which tracks the identity URLs of each user. I would like to store this in the usermeta table, but because it requires unique keys there’s just not a real clean way to do this and keep the plugin scalable to support large deployments. If this is fixed in 2.7, we could theoretically eliminate any custom database stuff in the plugin, which I’d absolutely love.

Removed PEAR_LOG

For the time being I’ve removed PEAR_LOG and am simply using error_log() for what logging still remains. The problem is that most people weren’t taking advantage of the logs anyway, so they were just taking up space. I’ll likely look at making use of the WP_DEBUG constant to allow more verbose logging when it’s desired. For now this just simplifies things a bit, and eliminates at least one case of library conflict that was reported.

Code Refactoring

Really? More refactoring? Didn’t I just do a lot of this in the last point release? Well yes, but more was needed… MUCH more. Previously, code was roughly divided based on the MVC (model, view, controller) model into store.php, interface.php, and logic.php, respectively. That worked for a while, but got to be pretty confusing as those individual files became a bit unmanageable. Instead, things are now broken into more logical segments… comments, admin panel, logging in through wp-login.php, etc. This seems to be a lot easier to manage and more importantly, easier to extend.

More Hooks

I haven’t sat down to document them all yet, but I’m adding in more hooks for other plugins to add functionality. Want to pull profile data from FOAF instead of sreg? No problem, now you have a hook you can implement. This makes everything in the plugin much more lightweight and “loosely joined” which is always good. All of the existing non-core OpenID functionality (like SREG) is currently using these hooks.

Bug Fixes

Though I’m not always good about replying, I generally do monitor the conversations on the WordPress support forums. I will try and put together a more exhaustive list of what bugs have been addressed, but I will simply say for now that most of the major bugs people have reported there should be absent from the current development branch.

Here Be Dragons!

Let me say first and foremost, don’t use this on a production blog. I always say that when I blog about unreleased code, but this time it’s much more important. There are major database changes in this version… changes which are non-trivial to reverse. There is a very good chance there will be more database changes before the final release, and there will not be an upgrade path from this development version (there will however be an upgrade path from the last stable version… 2.2.x).

What’s New

For now, I’m just going to have two follow-up posts talking about changes in the coming release. I’m sure I’ll overlook something and may have to add a third post, but for now we’re looking at:

• Making the plugin more stable, extensible, and overall simpler
• OpenID Providing and Delegation

Test it Out

The current plugin can be checked out from the DiSo subversion repository; grab the 3.0 branch . In addition, it requires a special branch of the XRDS-Simple plugin to provide all the XRDS publishing stuff. If you have a previous version of wp-openid installed, you must deactivate and reactivate the plugin for the database changes to be applied. Again, keep in mind that these will be somewhat substantial changes to the OpenID portions of the database, so don’t do this on your production blog just yet. Please direct any support questions to the DiSo Mailing List.

• What is your father’s middle name?
• What is the name of your first pet?

Questions which, if answered truthfully, are incredibly easy to guess with just a modicum of research. But if you make something up, then you’re likely to forget what answer you gave. It is widely agreed that these kinds of questions do not provide any real security, and there are a number of tricks people recommend for creating more secure answers. I have my own solution, so that’s not really the point of this post. This post is about what happened when I logged onto the Delta website today. After logging in with my four digit PIN (no, I’m not kidding… their website only supports four digit passwords), I was prompted to setup security questions for my account. My account which I’ve had since 2001, where I’ve deliberately chosen not to setup the optional security questions. However this time, I was notified that if I don’t setup security questions by September 17th, then I will lose access to my account. Delta has decided to make security questions mandatory now for all of their SkyMiles customers. That wouldn’t be so bad if it weren’t for what happens when you forget your security questions:

What happens if I can’t remember my security questions or answers?
If you forget the answers to the security questions, and you exceed the maximum allowable attempts to answer your security questions, your PIN will be emailed to the address stored in your SkyMiles profile. If you don’t have an email address on file then you can reset your PIN online provided you remember your personal information.

They simply email the PIN to you (in plain text) anyway! I’m not sure what kind of “personal information” you would have to provide if you don’t have an email address on your account, but it can’t be much more than address and phone number.

So I’m left wondering why on earth they are now forcing security questions down their customers’ throats. It would be one thing if they didn’t already have an automated password retrieval process, and this was an effort to cut support costs associated with forgotten passwords, but that’s not the case. It might also be acceptable if they recognized the danger of simply emailing passwords around in plain text, and so enforced this based on the incorrect belief that it’s more secure. But again, that is also not the case. All they’ve managed to do is to provide someone with yet another way to potentially gain unauthorized access to my account. If they really wanted to beef up security, how about allowing for more than a four digit PIN. If you really want to make things more secure, allow me to sign in using my OpenID which supports multi-factor authentication.

Of course I know this is not a unique problem by any means. Delta is not the only, nor the worst, offender. And I’m not really sure why someone would want to break into my Delta account anyway… there’s really nothing in there of any value. I know it was probably some schmuck at Delta with a three letter title and no clue about online security who forced the delta.com team to implement this. I know all this… it’s just really aggravating.

• POST replay for comments - this should fix all the compatibility issues with other comment related plugins like reCaptcha.
• MUCH better memory usage - like no longer needlessly building a 2MB object on every page load!
• support for Email Address to URL Transformation - now you can use an email address anywhere you normally use an OpenID
• fixed OpenID Spoofing vulnerability - users’ profile URLs must match one of their OpenIDs
• using hooks for gathering user data - other plugins can now hook in and gather user info from FOAF, hCard, whatever
• If OpenID authentication fails for whatever reason, the user is given the opportunity to submit their comment without OpenID
• lots of little fixes, code refactoring and cleanup, and a lot of UI tweaks

Download at http://wordpress.org/extend/plugins/openid/.

I tested pretty thoroughly on WordPress 2.2 through 2.6 using PHP5. I’m fairly certain I didn’t break PHP4, but let me know if you find any problems.

With this out the door, I’ll be jumping right into my feature list for the next major release — adding a native OpenID Server and delegation capabilities. At that point, it should be able to handle all of your OpenID related needs.