Learning the World

After upgrading to Mac OS 10.5.6 , I discovered that Mail would crash whenever I tried to open an email message, then blame my GPG Mail encrpytion plugin. To fix it, I had to upgraded to GPG Mail 1.20. You can download it here:

http://www.sente.ch/software/GPGMail/English.lproj/GPGMail.html

“You are in a maze of tiny, twisty passages, all a like”.

That line shows up in Zork and its variants when you get lost in a labyrinth, and it’s how I feel right now trying to puzzle through the best way (or hell, ANY way of securing WordPress Mu in directory mode).

What I’m trying to do is this:

• I want to enable secure logins and admin pages (so that these pages are protected via SSL and have https addresses).

I’ve got a WordPress Mu install setup in directory mode, e.g.:

• The main blog is at wordpress.foo.edu.
• The daughter blogs will appear in subdirectory format, e.g. wordpress.foo.edu/bar

In normal WordPress, this goal can be accomplished by setting two constants in the config file:

• define('FORCE_SSL_LOGIN', true);

• define('FORCE_SSL_ADMIN', true);

Another option is to make use of the Admin-SSL plugin:

• Admin-SSL: http://www.kerrins.co.uk/blog/admin-ssl/

With WordPress Mu, it seems things are a bit trickier. Ok, a lot trickier.

Both methods will protect the main blog at wordpress.foo.edu, I get nothing but 404s when I try and access any of the daughter blog admin pages at wordpress.foo.edu/bar/wp-admin. Traffic is successfully redirected to https, but the server simply spits out a 404 page, saying there’s nothing there to load.

This is the same thing that happens when you, ahem, forget to include the htaccess file with the various mod_rewrite commands that allow for clean urls in WordPress, so my assumption was I’d just need some more mod_rewrite magic to get WordPress to properly serve these pages.

This led me on a mad chase to try and figure out the best way to do that. Instructions in the following post seem like they should work:

• SSL/LDAP/password security questions

And yet not. More 404s. More headaches. It could just be that I’ve been working on this too long, and need to let it simmer overnight. It seems to me that there must be a way to use mod_rewrite to force Wordpress Mu to resolve these https addressses the same as it does http, but I’m just not seeing it.

My guess is that this all would work just fine using the subdomain method, but we really want to use the directory one.

So yes. There’s a maze. With tiny twisty passages. And they are all alike. Time to hit the reset button, and tackle it with new eyes tomorrow. In the mean time, if anyone has any bright ideas, please let me know.

Update: 2/2/2009

You knew it was going to be something small and obscure right? And you new it was going to be something that prevent the .htaccess file from firing, right?

When last I wrote on Friday, sub-blogs failed to load whenever you tried to access an https-enabled page. I couldn’t help having this gut feeling that my issue had NOTHING to do with .htaccess/mod_rewrite and everything to do with a server configuration issue.

On Sunday, I did some experiments, and I discovered that when I tried to load an SSL-enabled daughter blog, the htaccess file was never even executed.  I tested this by purposefully breaking the htaccess file so it would cause a server error; when I loaded https://wordpress.foo.edu”, I got a “page not found” not a “you idiot, you broke the server” error.

So I switched gears and started looking at issues with httpd.conf and ssl.conf. That’s when I came across the very nifty “Installing WordPress Mu” ebook [pdf], where I saw this bit of advice: 

Permalinks do not work or Can’t find subblogs in subfolder install
If everything looks like it installed okay, but when you start clicking on links and you get 404’s or server errors, you need to do a little Apache configuration. Even if you have mod_rewrite enabled, and the htaccess file is there, on some setups the web account is set to not let these settings through. You’ll need to go to terminal mode and edit the httpd.conf file. See back on page 5, and while you’re in there, look for the directive of your virtual host, find this line “AllowOverride None” and change it to “AllowOverride FileInfo Options”. With no quotes.

Sounds familiar … doesn’t it?

So I look at the wordpress entry in httpd.conf and see that yeah, AllowOverride is configured as “AllowOverride FileInfo Option”. But ssl.conf? THAT was set to “AllowOverride None” As a result, WordPress MU worked just fine on regular pages, but failed on secure ones.

Changing ssl.conf so that AllowOverride was set to “AllowOverride FileInfo Options” fixed the problem. Apache, htaccess and Wordpress are on speaking terms again, login/admin traffic is automagically routed to https, and the freaking page LOADS.

[sigh]. It’s only obvious in hindsight.