It is now possible to log in with OpenID, automatically creating an account, and to associate an existing account with an OpenID for future logins.

Personally, I suggest MyOpenID (from JanRain) because it gives the option of using PhoneFactor’s phone-call-based 2-factor authentication.

So, I’m posting this partly to spread the word and partly to see if the existence of this post will be successfully tweeted complete with short URL.

(NOTE: while YOURLS itself supported the IDN seamlessly, its WordPress plugin seemed to choke silently when pointed at the unicode form of the IDN for the YOURLS API and needed the punycode version to make it work.)

Edit: actually, OpenID login now seems to be entirely broken.  Hmm…

• what was the one and only login cookie in 2.5 is now limited to /wp-admin
• there’s a copy of that one that’s just limited to /wp-content/plugins, for backward compatibility with plugins
• there’s a new cookie that is at COOKIEPATH (which can be defined in your config file), that is checked by calling

  is_user_logged_in()

  (but perhaps this isn’t intended for secure authorization?)

So, it appears the way to go may be to change

auth_redirect()

to

Maybe more to follow on this when I’ve more thoroughly explored it.

The good news is that there’s an action hook, ‘set_auth_cookie’, that gets called whenever the cookies are set, so if the stuff for which you want to authenticate is on the same server but at a different path, you can create a plugin (or maybe use functions.php in your theme?) with something like the following:

The bad news is that if your WordPress install is at example.com/something and you want to use it to authenticate at portal.example.com, you can’t set a cookie for portal.example.com from a script on example.com, so your only choice would be to set a cookie with path / on .example.com (note the leading period), which completely breaks the security added by the separate cookies.

Hopefully, there’ll be a “part 3″ to this wherein I solve this last problem somehow, since that’s the setup I’m dealing with.

I, however, wanted a little more.  I wanted to make sure that regular users who might be, well, “curious” about the inner workings of the site and who have some knowledge of wp-admin URL structure to be unable to get at anything but their profile page.  To this end, I added a little to the code:

This should redirect any non-admin user off of any /wp-admin* page to /wp-admin/profile.php. This might, however, cause issues for mid-level users (i.e. authors/editors/etc may not be able to access needed functions) and I haven’t tested it thoroughly and there might be a better way to do this. YMMV.  See also some comment-discussion on these changes at the plugin’s own page: me Patrick me.

<?php wp_footer(); ?>

in the footer.php file, like they should, I guess, since that seems to be what the WordPress.com stats plugin needs to register hits.  I had been wondering why the numbers on my dashboards didn’t even remotely match my awstats numbers.

This is all fine and good, but still doesn’t quite work, since WordPress is smart and won’t just redirect anywhere willy-nilly.  It will only redirect to authorized-for-redirecting servers (wp_safe_redirect, which doesn’t have any documentation in the Codex).  Though undocumented (or at least not well documented in the Codex), the way the authorized host list is handled allows for a plugin to add a filter hook that modifies the allowed list (since the allowed list by default only includes the actual WordPress server name and isn’t exposed as an option/setting anywhere).  Toss that hook into my plugin, add on a settings page to allow the admin to input a comma-separated list of allowed-for-redirecting hosts, and now I can use WordPress to authenticate users on subdomains.

If anyone is interested in this plugin, please let me know and I’ll try to clean it up engouh to make it public.