The one way relationship between our user accounts and the MIS database also makes it difficult to engage with new users online. If you can’t get an account until you become a student, how do you allow potential students to apply online if all your systems are integrated with single sign-on? And if you can’t authenticate the online identity of your users, how do you set initial passwords into your system? Or allow them to reset a forgotten password online?

Internet companies never struggled with this issue, as their customers could only approach them online, but most universities built systems around paper applications and have fond (and relatively recent) memories of offering their students their first internet experience. It’s still not unusual for universities to offer their students their campus computing account with a default password based on supposedly secret data shared between the user and the school. But your SSN, birth date, and mother’s name are no longer secret. A proposed change in FERPA policy (see the the top of page 15586 in the NPRM) would have barred the use of “a common form user name (e.g., last name and first name initial) with date of birth or SSN, or a portion of the SSN, as an initial password to be changed upon first use of the system” in systems that store academic data. The final rule excluded that provision, much to the relief of those schools with more lobbying clout than brains.

Platform Choices

Rather than wait to see how the ruling played out last year, we went to work trying to improve security while easing access to our systems (no, that is not self-contradictory). Our challenges were thus:

• Fix initial password assignment
• Fix password resets
• Allow users with a loose or undefined relationship to the institution to create limited accounts for the purpose of interacting with the institution or its members

We considered a number of paths to a solution, including hacking of our university portal (which hosts the CAS single sign-on in our environment), expansion of a limited home-built solution, and a review of commercial and open source products and frameworks. We simplified the problem by confirming that the FERPA rule did not require us to authenticate the “real life” identity of a person; rather, we had only to validate the online identity of a person (saving us from needing to do things like send confirmation PINs by postal mail to a person’s home address).

In the end, we chose WordPress MU. Significant factors were our experience with the software (all the MIS developers use it personally), the extensibility of it as an application platform, the development focus on user experience (especially in recent versions), and our interest in using it as a framework for other user-facing services (especially BuddyPress).

Our Needs vs. WordPress

• The system must serve as the front end to our single sign-on environment, using our AD and LDAP password stores to authenticate users who have accounts in those systems.
• External email addresses, once verified with some challenge/response, can be used to reset a password.
• Users who are presently affiliated with the school have a school-provided email address, but no external address with which to reset their lost passwords.
• Users who are not presently affiliated with the school have no school-provided email address, and must verify their external email address before their account is activated. They can then set their own password once they verify their email address.
• The ability to send password reset codes via SMS would be nice (especially considering the number of long-time employees of the university who do not have personal email accounts), though that also requires the verification of the user’s cell phone number.

After reviewing what we wanted to do, we surveyed WordPress’ code to develop an implementation plan. And, because a number of aspects of our application process were changing, we decided to focus on allowing current users to self-reset their password and postpone development of account self-creation features for new users. Still, a few issues quickly emerged:

• WordPress requires a username be assigned to each user, rather than relying on email address (this is likely to change in WP 2.9) Creating a new username for our users is unacceptable, but adding a large number of new users to our existing username space will quickly deplete the “good” usernames. And changing a user’s username as their affiliation with the institution is unacceptable.
• The core user authentication function can be replaced with our own function. (And in 2.8 it became filterable)
• WordPress MU will validate email addresses, but the system isn’t built to be extensible.
• WordPress only stores one email address per user, but the user meta system can be used to store a second one. Unfortunately (and in a manner inconsistent with post meta), only one value per meta key per user is allowed, making it difficult to allow users to have an arbitrary number of email addresses associated with their account.
• The function that identifies a user by a given email address can be replaced with a function that also checks the secondary address.
• WordPress user profiles have no phone field, but the user meta system can be used to store one. A function to identify a user by a given phone number must also be created.
• Unlike some settings pages, the fields on the user profile editor cannot be changed simply by modifying the $wp_settings_fields array.
• Upon doing a password reset, the user is sent a temporary password, rather than being allowed to set a new password. This contradicts University policy about how passwords are used and communicated and could train users that sending passwords by mail is acceptable.
• The various functions in wp-login.php cannot be replaced, and in WP 2.7 the code had no way to add or replace various login actions (WP 2.8 changed that).
• WPMU-specific functions don’t always follow WP coding standards or models.

(Note that we began our work and deployed the system under WPMU 2.7. WPMU 2.8 included a few changes that made the process easier. I’m proud to say that some of those changes were a result of code we offered back to WP during our development.)

What We Did

• We decided that email addresses (both PSU addresses and external addresses), as well as PSU usernames would be acceptable identifiers for an account, and that a person should be able to log in to our web services using any of those identifiers. So…
• We replaced wp_autenticate() with our own function that accepts either email address or university username, checks to see if the user exists locally, checks to see if they exist in AD or LDAP, confirms their password, provisions their WordPress account (for university users who’ve not logged in via this method yet), establishes a session with our university portal and redirects them there (unless $redirect is set to something more specific that the dashboard).
• We decided to replace WordPress’ usernames with a random string matching a pattern we established. This became the WPID. Doing this required us to hide references to username (easy if you set a preferred display name)
• To store phone numbers and secondary email addresses, and allow users to edit those within their profile, I created the Alternate Contact Info plugin (browse source). This requires more use of output buffering than I’d like, but it gets the job done.
• To confirm email addresses and phone numbers via a challenge/response message (and support other interactions), I created the WordPress Ticket Framework plugin (my introduction, browse source).
• To send messages via SMS, we used my wpSMS plugin (in the plugin directory, browse source).
• Matther Batchelder re-skinned the login screen via a plugin that inserts our custom CSS.
• After determining that our university portal could not be made to authenticate via CAS, I gave up work on my wpCAS Server plugin and developed another method to initiate the portal session (which then establishes a CAS session using the portal’s CAS server).
• We replaced most of the functionality of the wp-login.php page (by hacking core at first, then taking advantage of the action hook in 2.8). In doing so we were able to change the password reset behavior to allow users to immediately change their password after entering their reset code (which was sent to their email address or phone via SMS).

Over time we extended the system to host multiple domains and replace our CMS. Soon we’ll consolidate our  public blogging instance into it, and we’re building an invite system that we can use to invite people to join our community.

What It Looks Like

The re-skinned WordPress login

Entering an email address or username to get a password reset code

SMS text with password reset code

Enter the password reset code from the SMS text message here, or follow the link from the email

Extended contact information in the WordPress profile

And that’s how we replaced our authentication system with WordPress, gained self-service password resets, and built the foundation to invite new users into our system.

• site.org/blogname1
• site.org/departments/blogname2
• site.org/departments/blogname3
• site.org/services/blogname3

The association between blog IDs and sub-directory paths is determined in wpmu-settings.php, but the code there knows nothing about nested paths. So a person planning to use WordPress MU as a CMS must either flatten his/her information architecture, or do some hacking.

Challenge: hacking WordPress MU to support arbitrary directory paths for each blog

As with my multi-domain hack, the following assumes that you’re using the vhost=no setting, that you have access to and know how to manipulate your MySQL, that you have control over your DNS and know how to use it, and that you know how to configure Apache or similar. You’d also be smart to turn off any object caching you may have running, at least until we’re done doing direct database manipulation. The following also assumes that your wp-config.php sets the DOMAIN_CURRENT_SITE and PATH_CURRENT_SITE constants — if you’ve done a fresh install recently, it probably does, or you can check my domain mapping hack.

Hack The Path Mapping

Right at the top of wpmu-settings.php you can see how it strips all but the base of the URL path, but rather than mod that file, we can take advantage of an obscure MU hack: sunrise.php, which gets executed after some important WordPress components like the database class get loaded and before wpmu-settings.php.

To use sunrise.php, create a PHP file at /wp-content/sunrise.php and set define('SUNRISE', TRUE); in your wp-config.php.

Here’s the sunrise.php code I’m using:

if( defined( 'DOMAIN_CURRENT_SITE' ) && defined( 'PATH_CURRENT_SITE' ) ) {
	$current_site->id = (defined( 'SITE_ID_CURRENT_SITE' ) ? constant('SITE_ID_CURRENT_SITE') : 1);
	$current_site->domain = $domain = DOMAIN_CURRENT_SITE;
	$current_site->path  = $path = PATH_CURRENT_SITE;
	if( defined( 'BLOGID_CURRENT_SITE' ) )
		$current_site->blog_id = BLOGID_CURRENT_SITE;

	$url = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );

	$patharray = (array) explode( '/', trim( $url, '/' ));
	$blogsearch = '';
	if( count( $patharray )){
		foreach( $patharray as $pathpart ){
			$pathsearch .= '/'. $pathpart;
			$blogsearch .= $wpdb->prepare(" OR (domain = %s AND path = %s) ", $domain, $pathsearch .'/' );
		}
	}

	$current_blog = $wpdb->get_row( $wpdb->prepare("SELECT *, LENGTH( path ) as pathlen FROM $wpdb->blogs WHERE domain = %s AND path = '/'", $domain, $path) . $blogsearch .'ORDER BY pathlen DESC LIMIT 1');

	$blog_id = $current_blog->blog_id;
	$public  = $current_blog->public;
	$site_id = $current_blog->site_id;
	$current_site = sl_get_current_site_name( $current_site );
}

function sl_get_current_site_name( $current_site ) {
	global $wpdb;
	$current_site->site_name = wp_cache_get( $current_site->id . ':current_site_name', "site-options" );
	if ( !$current_site->site_name ) {
		$current_site->site_name = $wpdb->get_var( $wpdb->prepare( "SELECT meta_value FROM $wpdb->sitemeta WHERE site_id = %d AND meta_key = 'site_name'", $current_site->id ) );
		if( $current_site->site_name == null )
			$current_site->site_name = ucfirst( $current_site->domain );
		wp_cache_set( $current_site->id . ':current_site_name', $current_site->site_name, 'site-options');
	}
	return $current_site;
}

The first few lines of the code do pretty much the same as the start of the wpmu_current_site() function in wpmu-settings.php, but starting with line 8 it takes a big departure.

That’s where it splits the requested URL path like /path/to/blog/and/stuff/ into pieces and constructs an SQL query against the wp_blogs table to identify the correct blog to serve the request. The following example shows how:

SELECT *, LENGTH( path ) as pathlen
	 FROM wp_blogs
	 WHERE domain = 'domain.org' AND path = '/'"
	  	 OR (domain = 'domain.org' AND path = '/path/')
	 	 OR (domain = 'domain.org' AND path = '/path/to/')
	 	 OR (domain = 'domain.org' AND path = '/path/to/blog/')
	 	 OR (domain = 'domain.org' AND path = '/path/to/blog/and/')
	 	 OR (domain = 'domain.org' AND path = '/path/to/blog/and/stuff/')
	 ORDER BY pathlen DESC
	 LIMIT 1

Optimization note

Setting a maximum depth (and array_slice( $patharray, 0, $maxdepth )) would allow the query to be cached up to that depth. Otherwise, the query must be executed for every page load. The $maxdepth could either be set arbitrarily, or could be determined automatically based on the maximum path length of registered blogs.

Setting Up New Blogs

Once you’ve hacked the path mapping (and tested that it didn’t break your current site), you can add a new blog at a nested path.

Create a new blog in the MU blog admin.

Unfortunately, MU strips the slashes from the URL path you just tried to set.

The new blog you just tried to create, but with a very different path.

Fortunately, you can set the path correctly in the MU blog editor, and it won’t break the path when you save there.

Set the blog path in the MU blog editor, MU won't break it when you save it this time.

Once you create the new blog, try to load it in your browser. You’ll quickly notice the stylesheet is missing, though the blog works and functions properly.

Hack The .htaccess

WPMU uses the following .htaccess rewrite rule to properly direct requests for files on the real filesystem:

RewriteRule  ^([_0-9a-zA-Z-]+/)?(wp-.*) $2 [L]

Obviously, that rule won’t work for deep paths, so I’ve replaced it with this rule:

RewriteRule  ^(.+)?/(wp-.*) /$2 [L]

And with that, you should be done.

WordPress MU is a solid CMS to support a large organization. Each individual blog has its own place in the organization’s URL scheme (www.site.org/blogname), and each blog can have its own administrators and other users. Groups of blogs in WPMU make up a “Site” and one or more Sites can be hosted with a single implementation. (I’m capitalizing Site for the same reason WordPress docs capitalize Page) Each Site has a defined set of administrators and options controlling various features. You might, for instance, lock down the plugins on your blogs.site.org, while keeping it open on your www.site.org. Or maybe you’d like to let your helpdesk staff create new blogs at blogs.site.org, but not at www.site.org. That’s what WPMU’s notion of Site can help you control.

Challenge: setting up service on multiple (sub-) domains

WordPress MU makes it easy to host both blogs.site.org and www.site.org within a single implementation, but there’s little documentation for how to do it.

Once you get WPMU up and running on one of your domains you can add another. The following assumes that you’re using the vhost=no setting (correct: I really mean vhost=no), that you have access to and know how to manipulate your MySQL, that you have control over your DNS and know how to use it, and that you know how to configure Apache or similar. You’d also be smart to turn off any object caching you may have running, at least until we’re done doing direct database manipulation.

Some might ask why I’m not simply using Donncha’s plugin, and the answer is simple: it only works for vhost=yes sites. For my own use, I find that sub-directories are easier for users to make sense of (go ahead, try to tell your mom to go to “myblog.sub.domain.org“).

Set up your web server

If you’re using Apache, you’ll either need to create an IP-based virtual host or manually configure your name-based virtual host for every (sub-)domain you plan to serve. Why: WordPress will handle the domain mapping for you, so it’s better to keep Apache out of the way and let WPMU own the entire IP.

Set up your DNS

Point each subdomain you plan to host in WordPress to your webserver. You can use a wildcard domain, but you don’t have to.

Create a new blog in WPMU

It doesn’t matter what you call it or what the path is, just create one. Now go edit it in the Site Admin:

Change the domain and path to match your new domain.

One quirk of WPMU is that it strips “www” from any domain name you enter (or is requested), so don’t bother trying to enter it (unless you’re willing to do some hacking to make it work). WPMU stores domain and path information in three locations: the wp_#_options table for the blog, the wp_blogs table, and the wp_sites table. When you edit a blog in the Site Admin, you’ll get a chance to edit the domain and path for both the wp_#_options and the wp_blogs tables. Clicking the helpful checkbox above will do most of that for you, but you’ll need to manually update the Upload Path.

Now make sure the new domain is shown in the blog's options as well.

You might be able to load the blog at the new URL as soon as you update those settings, but recent versions of WPMU set some constants in wp-config.php that can get in your way.

Reconfigure wp-config.php

Your wp-config.php might have something like this:

$base = '/';
define('DOMAIN_CURRENT_SITE', 'sub.site.org' );
define('PATH_CURRENT_SITE', '/' );
define('SITE_ID_CURRENT_SITE', 1);
define('BLOGID_CURRENT_SITE', '1' );

Those constants override the database checking that goes on in wpmu-settings.php to map the requested domain to a site. You have three choices: leave it as it is (and use only one “Site”), remove it and have WPMU do the mapping against the database, or expand the hard-coded mapping to include other sites.

I’ve used code like the following to do just that:

if( preg_match( '/(.+?\.)?([^\.]+?)\.site.org/i', 'www'. $_SERVER['SERVER_NAME'] , $matchedsubdomains ))
{
	switch( array_pop( $matchedsubdomains )){
		case 'connect':
			define('DOMAIN_CURRENT_SITE', 'blogs.site.org' );
			define('PATH_CURRENT_SITE', '/' );
			define('BLOGID_CURRENT_SITE', '1' );
			break;
		case 'www':
		default:
			define('DOMAIN_CURRENT_SITE', 'site.org' );
			define('PATH_CURRENT_SITE', '/' );
			define('BLOGID_CURRENT_SITE', '2' );
			break;
}
}
else
{
	define('DOMAIN_CURRENT_SITE', 'site.org' );
	define('PATH_CURRENT_SITE', '/' );
	define('BLOGID_CURRENT_SITE', '2' );
}

Set up your new Site

Once you have your new sub-domain working with one blog, you can create your new Site. Even if you don’t plan to create separate management policies for the different sites, it’s easier to create new blogs at each sub-domain if they each have their own Site.

Go in to your MySQL tool of choice and browse the wp_site table. There you’ll see just one row, but if you’ve made it this far you can also probably figure out how to create a new row representing the site at the new sub-domain. And once you do that, you can change the entry in the wp_blogs table to associate it with your new Site.

Set up the admins of the new site

Creating the new entry in wp_site doesn’t set the options for the new Site, and that means there are no Site administrators yet. Once again in your MySQL tool of choice, open up the wp_sitemeta table and look for an entry with meta_key = 'site_admins'. The meta_value for that entry is a serialized array containing WordPress usernames of the people who have site-wide administration privileges on the first Site. I’m assuming that if you have MySQL access you’re also a Site admin, so the easy thing to do is copy that row and change the site_id to match the auto-increment value from the new wp_site entry you made in the last step.

With the database manipulation done, you should now be able to go to the WP dashboard at your new Site, visit the WPMU admin options screen, and set the other options as necessary. You could decide to make one of your Sites open registration (remember, however, that users are shared across all Sites), while making other Sites more closed. And, obviously, you can delegate different Site admins for each Site.

Sub-domains or just different domains?

It’s worth noting that the instructions so far apply to both sub-domains and domains. You can use a single implementation of WPMU to manage content at both lolzors.org and tehsite.org. The detail about sub-domains really only applies to the next part. It’s also worth noting that you can support an arbitrary number of blogs, sites, and domains; I’m just using two sub-domains as an example.

Challenge: unified log in cookies

What’s the point of hosting multiple sub-domains with one WPMU implementation if you’ll need to log in separately at each one?

Set your cookie path

Setting a cookie path that that’s broad enough to cover the entire domain will solve this:

define('COOKIE_DOMAIN', 'site.org');
define('ADMIN_COOKIE_PATH', '/');
define('COOKIEPATH', '/');
define('SITECOOKIEPATH', '/');

Avoid conflicts with other WordPress installations at your domain

But having such a broad cookie domain can interfere with other WordPress implementations. You’ll have to solve that by setting a unique cookiehash:

define( 'COOKIEHASH', 'asdf_arbitrary_string' );

You’d do better to keep it shorter than that, though.

Challenge: unified log in location/URL

WordPress MU is happy to handle authentication requests wherever it hosts a blog, but some organizations prefer to funnel all authentication requests through a single location. The idea is to provide some protection against fishing (assuming users can ever be taught to look at URLs) and make it easer to integrate external applications.

Filter login_url and logout_url

Set the log in and log out path to whatever you want, just make sure the destination knows how to create (or destroy) the WordPress cookies.

$hack_base_domain = 'site.org';

function hack_login_url( $path ){
	global $hack_base_domain;

	return preg_replace( '/^.+?\/wp-login.php/' , 'https://login.'. $hack_base_domain .'/wp-login.php', $path );
}
add_filter( 'login_url' , 'hack_login_url' , 10 );
add_filter( 'logout_url' , 'hack_login_url' , 10 );

Filter allowed_redirect_hosts

WP will normally block redirects outside the web root of the active blog, so you’ll need to tell it about your other sub-domains.

function hack_allowed_redirect_hosts( $allowed_domains ){
	global $hack_base_domain;

	$allowed_domains[] = $hack_base_domain;
	$allowed_domains[] = 'www.'. $hack_base_domain;
	$allowed_domains[] = 'blogs.'. $hack_base_domain;

	return $allowed_domains;
}
add_filter( 'allowed_redirect_hosts' , 'hack_allowed_redirect_hosts' , 10 );

An amusing hacks-conference lightning talk-turned-blog post on web development: “Graceful Hacks” – UX, IA and interaction design tips for hack days. Martin Belam’s talk at The Guardian’s July 2009 Hack Day must have been both funny and useful:

• Funny: “However, I am given to understand that this is now deprecated and has gone out of fashion.”
• Useful: “the Yahoo! Design Pattern Library is your friend.”

Two interesting submissions to the Core77 Business Card Hacks Challenge: earbud speakers and a cord winder.

You’ve got the hardware, you’ve got the skills, go build a multi-touch electronic whiteboard with your Wiimote and a data projector.

First, Josh Porter, the first speaker of the day has a blog where he’s posted his presentation notes and some key points. Josh spoke about Web 2.0, and ended with the conclusion that successful online technologies are those that best model user behavior. “I think Web 2.0 is about modeling something that already exists in our offline worlds, mostly in the spoken words and minds of humankind.”
Interestingly, in findability terms, it was Josh’s post that clued me in that the event podcast was online because he linked to my blog in his post. Lesson: links make things findable.

Like Josh, I found my voice a little unfamiliar, but you can listen here (51MB) if that’s your thing.

Also, I demoed some features I’d like to see in a future OPAC, but to help people visualize them, I finally put together a graphical mockup of them here.

tags: asist, authentication service, buy hack or build, databases, hack, hacks, libraries, library, library catalog, library services, neasis&t, neasist, opac, opac hacks, university portal

I was tempted to speak without slides yesterday, and I must offer my apologies to anybody trying to read them now, as I’m not sure how the slides make sense without the context of my speech. On that point, it’s worth knowing that Lichen did an outstanding job liveblogging the event, despite struggling with a blown tire earlier that morning.

It’s probably well understood by anybody reading this that most library services are at the web 1.0 stage. My slides show a number of screenshots of our current library catalog, but my speech went something like “I’m not here to tell you how we re-painted, re-wallpapered our catalog….” So, skip past those slides, and read here for context.

My following points were about some of the hacks I’d put into production to bring our library services up to about web 1.5 status. They include an awareness that library services include not only the OPAC, but also our website and a number of databases. We’ve all encountered difficulty trying to describe the different reasons to use each of these resources, but our patrons have less and less patience for it. Among the barriers to use is access. Even when our databases are freely available on campus, off-campus use often requires a special password for one stage or another of the process.

The slides demonstrate our current solution. By integrating our resources into the university portal and leveraging the authentication service it provided, I was able to hack single sign-on access to our databases and patron self-service module. This lowered the barriers to access, and we saw our usage of those resources increase dramatically.

All this was good, but it still wasn’t web 2.0, and it revealed a larger problem looming ahead: identity management. The more we try to provide individualized, customized, targeted services, the more we’ll bump into that issue of how we identify our patrons.

Moving forward to our web 2.0 future, I wanted to posit the idea that one of the most useful recent developments is the way we can now separate the tools that store and manage our data from the tools that display and manipulate our data. Yes, I’m talking about APIs, Webservices, XML, RSS, REST, SOAP, et all.

As examples, I offered a personal vacation map (using Google Maps), the Colr Pickr (using Flickr), our reviews and bookjacket pages (using Amazon), and this silly home made search engine (using Yahoo, Technorati, Amazon, Flickr, and Wikipedia).

Even more specific to libraries, I offered my OPAC suggest, A9.com integration and this functional (but not pretty) prototype of how I’d like to make subject headings a more prominent part of the search process.

So, you’re free to go through my slides, but you might do better to read around here and at LibDev. If you do go through the slides, be sure to follow the links out to websites. I didn’t visit even half of them during my talk, but I put them there to offer some redeeming value on review.

tags: asist, authentication service, buy hack or build, databases, hack, hacks, identity management, libraries, library, library catalog, library services, neasis&t, neasist, opac, opac hacks, university portal

I’m here at the NEASIS&T Buy, Hack or Build event today at MIT’s Media Lab. On the list are Joshua Porter, Director of Web Development for User Interface Engineering, Pete Bell [corrected], co-founder of Endeca Solutions, and me.

I’m posting my slides here now, but I’m told we’ll see a podcast of the proceedings soon after the conclusion. Be aware that the slides are full of links. I won’t be able to explore them all during the presentation, but they might add value later.

tags: asist, buy hack or build, hack, hacks, libraries, library, neasis&t, opac, opac hacks