WordPress locked down with HTTP Basic Auth

I run several WordPress sites for other people (this isn’t one of them). A couple of them are private: no password for the site, can’t read the site. For years I’ve had an unwieldly situation in which the lockdown was implemented with HTTP Basic Auth configured in Apache, and the users separately log into the site in order to post.

I used HTTP Basic Auth for locking it down even after I discovered Authenticated WordPress (requires a login as a WordPress user before you can see anything) partly because it’s accessible to RSS readers. Many RSS readers (and assorted web fetching tools) can speak HTTP Basic Auth. Few can log themselves into WordPress, although I wouldn’t be surprised to find an exception or three. Eventually though different search terms led me to the HTTP Authentication plugin, and it turns out they play nicely together. If you install them both the site requires HTTP authentication in order to access any part of it, and any person who has successfully authenticated is logged into WordPress too.

A couple of niggles:

  1. (The HTTP Authentication plugin requires that you have two matching lists of user names (well, actually one can be a proper subset of the other if you like, but users who aren’t in both can’t authenticate): the WordPress DB needs to have a registered user, and the external authentication source needs to have an entry for the same user.) Actually, I tell a lie. There is an option to automatically create a WordPress account for a user who shows up as successfully authenticated with an unknown user name.
  2. The HTTP Authentication documentation is slightly wrong: you don’t need the nickname to match the external user, you need the username to match the external user (which is the sensible way anyway).