Flock and self-hosted WordPress

NOTE: This article is out of date and likely obsolete.

I reinstalled Flock and figured out what was preventing it from talking to my self-hosted blog, K-Squared Ramblings. The site is running on a stand-alone WordPress install, and I kept getting 403 Forbidden errors. (Not that I could tell. Flock hid the error and just told me something went wrong setting up the account.)

It turned out to be a setting in mod_security, an Apache module designed to limit attacks on web applications. Part of the sample filter—one that I kept because it seemed a reasonable precaution—was to block POST requests with content types other than application/x-www-form-urlencoded or multipart/form-data. However, XMLRPC uses text/xml, which was getting blocked.

There weren’t any problems reported, and none of the false positives I saw in the logs were related to the request content-type. So by the time I tried setting up Flock, it didn’t occur to me to check the mod_security log. I just figured it was a problem with my version of WordPress and left it at that.

This time, with a newer version of Flock, I decided to investigate. I found the 403 error in the server logs, checked the error log for detail, and saw the mod_security reference. A quick check of the audit logs, and there it was.

For now, I’ve loosened the content-type requirement slightly. I’ll have to decide whether it’s worth keeping XMLRPC enabled, or whether I’m better off restoring the original rule.

Add these to your ModSecurity settings:

SecFilterSelective REQUEST_METHOD "!^(GET|HEAD)$" chain
SecFilterSelective HTTP_Content-Type "!(^application/x-www-form-urlencoded$|^multipart/form-data;|^text/xml$)"

So, the moral of the story is: If you can’t post to your self/third-party-hosted WordPress blog through a program other than the website, and you use ModSecurity - check those settings.