<?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.

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.

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.

There seems to be two kinds of hackery going on, just like I’ve described:

1. Inserting “invisible” HTML full of links (for NSFW sites) into your WP template that isn’t obvious when you go to your blog, but is VERY obvious when you look at the source code (and start seeing that you’re getting traffic for some “peculiar” terms).

2. Inserting whole new source code / new sneaky themes that copy other blogs / content *exactly*, which is full of spammy content and affiliate links.

(Vulnerable WordPress Blogs Not Being Indexed > Massive Blog Hackery Exposed > TailRank Exposes Massive Number of Blogs Hacked) It seems like if you’re running WordPress, it’s advisable to upgrade to 2.5 (which was relatively painless) as well as checking the actual code of your theme…