WordPress and basic authentication, problems with WP Cron and file uploads

I have a Google ego search on my name, so I can keep track of what the Internets is saying about me behind my back. The other day the ego search summary email arrived and included was one of my development sites. Which was annoying because I don’t want people browsing around my development, it might be broken or confuse people by looking like a live site (but not contain proper content). So I did what I should have done from the beginning and enabled Basic Authentication on my development sites. (Basic Authentication protection provides those “popup passwords” you see around the place where a little, usually grey, dialog pops up asking for a username and password before you can go any further.)

Basic Authentication is as old as the hills in internet terms, and while it’s not the most sophisticated protection it’s a reliable and simple way to prevent any old Tom, Dick or Harriet poking around where you don’t want them. I’ve used it before for client sites which are hosted on the open internet, but where we only want a small selection of people to see it… add Basic Authentication and bosh, job done.

As I was using WordPress adding Basic Authentication was easily achieved by adding this block of code to the .htaccess at the root of the WordPress files:

# Setup Basic Auth
AuthUserFile /opt/local/apache2/conf/.htpasswd
AuthName "My WordPress Development Site"
AuthType Basic
Require valid-user

You won’t be able to just copy and paste this block unfortunately, as your AuthUserFile will need creating, and it’ll be in a different file path to that shown, etc. Ask your ISP, or google around for some advice on this.

All was well in the world, and I was smugly sure that no more of my development content would sneak into Google’s index and confuse people. Then one day I tried to upload a file and hit this error:

“An error occurred in the upload. Please try again later.” Hmmm… not the most helpful error message I’ve ever seen (note to self: submit change to WordPress to make this more helpful). After a little digging, I found the relevant error in my Apache server error logs:

127.0.0.1 - - [21/Feb/2009:07:50:27 +0000] "POST /wordpress/wp-admin/async-upload.php HTTP/1.1" 401 533

The key element of that error line above is the “401” near the end, that’s the HTTP Status Code which Apache sent back when the WordPress upload script tried to upload the file. A 401 code means “the request requires user authentication”, so for some reason the upload script (which is written is Flash from what I recall) isn’t sending the proper authentication to the Apache server (remember that popup dialog from earlier, in metaphorical terms Flash is ignoring it and so the server is ignoring Flash).

The solution is pleasantly simple, just tell Apache to exempt this file from the authentication. This is fairly simple to do, and I added this FilesMatch block of code to my .htaccess:

# Exclude the file upload script from authentication
<FilesMatch "(async-upload.php)$">
Satisfy Any
Order allow,deny
Allow from all
Deny from none
</FilesMatch>

If you had a similar authentication problem with another file, maybe an external site needs to ping your server with some information or something, then you could add another file by changing the FilesMatch block like this:

<FilesMatch "(async-upload.php|admin-ajax.php)$">

So now there’s no excuse for my development sites ending up in search engine indexes. Incidentally this solution isn’t WordPress specific, it will apply to any website running on Apache, so don’t feel left out if you’re not a WordPresser.

Update (1st March 09): I’ve now encountered similar problems with WP Cron, which also uses network connections to trigger stuff. You can alter your FilesMatch block in .htaccess so it looks like the following to fix this issue.

# Exclude the file upload and WP CRON scripts from authentication
<FilesMatch "(async-upload.php|wp-cron.php)$">
Satisfy Any
Order allow,deny
Allow from all
Deny from none
</FilesMatch>