Ah-ha!  A cookie problem–while I’d set the cookie domain for WordPress to allow subdomains to work, bbPress didn’t know about WordPress’s cookie settings, so bbPress didn’t set the right cookie domain.  Worse, this meant that the cookie didn’t quite match up to what WordPress expected, so logging out in WordPress tried to blank a cookie that wasn’t set, not the login cookie set by bbPress.  The fix is to add something like

$bb->cookiedomain = '.yoursite.com';

to bb-config.php (that is, match what you’ve set in WordPress). Not the most obvious way to set an option, but it works.

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.

It’s a fairly straight-forward process.  At its simplest:

Including wp-config.php (you may have to watch the path) gets you just about all of WordPress and auth_redirect() will check if the user is logged in to WordPress and if not, they get bounced to a login form.

Where things get trickier is if you want to use the authentication on a subdomain (you have to tweak COOKIE_DOMAIN in wp-config.php [to override what’s already in wp-settings.php) or if your blog is in a subdirectory and you want the authentication outside that subdirectory (try tweaking COOKIEPATH).

Oh, and if you try to put the require_once() statement inside a function, you will also need

global $wpdb;

or nothing will work.

The issue of how much memory it consumes to load all of WordPress just to authenticate users is a whole separate issue.

(Oh, and unrelated to CAPTCHAs, I am right now grateful for the autosaving of drafts in WordPress, since, when I went to the hosting provider’s web site to check that I was correctly quoting them, I experienced the fourth crash of Firefox 3b5 tonight, all four of which have occurred when clicking on some part of this hosting provider’s control panel.)

I hate CAPTCHAs, but I think they are (in some instances) a necessary evil.  I have, in fact, even written my own in PHP, using a lot of the CAPTCHA-defeating research as a guide for building a computer-resistant but human-readable CAPTCHA, but again I’m getting away from my intended point.  To me, a CAPTCHA is a roadblock of last resort.  It’s annoying to your users, so if you decide to employ a CAPTCHA, either you don’t care about your users or you’re overrun with bots that cannot easily be stopped any other way.  The only places I’ve employed CAPTCHAs are on guestbook-type pages where the volume of spambot comments were such that I was hitting a disk quota issue and on account signup pages.  This hosting provider, however, wants me to deal with a CAPTCHA whenever I want to do anything with the account at all because, they say, they want to prevent automated login attempts.  Wouldn’t rate-limiting be a much better solution?  Maybe looking at user agents?  Javascript?  How about using something like Bad Behavior?

Ahh, well.  I’ll transfer the domain name out now, and when the hosting plan is up in about 16 months (2-year auto-renew, happened just before I took over), I’ll be moving that web site elsewhere.