Of course, it’s also annoying that while there’s a set_auth_cookie action hook, there’s no clear_auth_cookie, so my plugins had to override the clear_auth_cookie function wholesale rather than hooking into it as they do with set_auth_cookie.

If you have some twisted desire to make this unholy integration that I now seem to have working and would like some of my code, leave me a comment.

However, I just came across this in the bbPress forums:

As of July 2008, do NOT try to integrate WordPress 2.6 with bbPress 0.9 Use WP 2.5.1 – the reason for this is simple – WordPress has radically changed the way cookies are used. If you have already installed WP 2.6, don’t worry you have not broken anything, you’ll just need to downgrade and install 2.5 instead. 2.5.1 is perfectly stable and has no known security issues – 2.6 only adds a few new features to WP. There is an updated version of bbPress in the works to support the new cookie method but it might be awhile before it’s available in a mainstream release.

Now, ostensibly, WP and bbPress are coming from the same people/place/company/organization/whatever, so I think I should be able to expect the one to work with the other and to *not* have the left hand tell me to ignore what the right hand is doing.  This is almost enough (*almost*) to make me give up on trying to piece together a decent way to hook into the is_user_logged_in() thing for the non-WP part of the WP-based site I’m working on, since the bbPress part of the site won’t work even if I do fix the non-WP part of the site.

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.

To make cookies secure against attacks where someone has managed to get into your database through an SQL injection exploit or other means, WordPress 2.5 introduced a user-definable constant called SECRET_KEY. If you look at the sample wp-config.php shipped with 2.5, you’ll see these lines.

// Change SECRET_KEY to a unique phrase. You won’t have to remember it later,
// so make it long and complicated. You can visit https://www.grc.com/passwords
.htm
// to get a phrase generated for you, or just make something up.
define(’SECRET_KEY’, ‘put your unique phrase here’); // Change this to a unique phrase

If you upgraded from a previous version of WordPress you probably won’t have these lines in your wp-config.php.

That last bit is, of course, the critical thing for me and had me going back and inserting SECRET_KEYs into all my older/upgraded WordPress installs.  Just remember that if you’re integrating with bbPress, you have to match the SECRET_KEYs in wp-config.php and bb-config.php.

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.