Tom McGee's Blog

When you use Movable Type for multiblogging, sometimes you’re going to find that you want to keep readers out altogether. But that’s not an option out-of-the-box. There are various plugins you can try that may or may not work. And password protecting certain posts is a headache both for you — you must remember to apply a password to every post — and your readers — they have to log in every time they click a new link. And it doesn’t hide the post or it’s summary. At some point you may need to just keep random people out.

If you’re running Apache with mod_env enabled, you can configure your httpd.conf or set up an .htaccess file to do it.

mod_env allows you to create environmental variables on the fly, based on criteria you set. In the case of MT, you can check for certain cookies that the application sets. The ones we used were mt_user and commenter_name.

Assuming you have a finite list of readers or commenters, you can test for their name in a cookie like this:

SetEnvIfNoCase Cookie mt_user=readerone readblog
SetEnvIfNoCase Cookie commenter_name=john%20doe readblog
SetEnvIfNoCase Cookie mt_user=readertwo readblog
SetEnvIfNoCase Cookie commenter_name=jane%20roe readblog

mt_user contains the users logon name. commenter_name holds the users display name, with any spaces replaced with “%20″ (which displays as a dot). SetEnvNoCase tests the existing variable “Cookie” against “mt_user=readerone”, which can be a string or a regular expression. If it tests true, it sets a variable in the environment “readblog”. You can use Firebug’s Net panel to see what the cookie looks like as passed through the HTTP request.

Next, use the <Limit> block to set up the restrictions:

<Limit GET POST>
order deny,allow
deny from all
allow from 127.0.0.1
allow from env=readblog
</Limit>

“allow from 127.0.0.1″ makes sure that Movable Type itself can POST to the directory. “allow from env=readblog” tests to see if the variable has been set above. “readblog” can be anything you want. You could set up several tests, and allow POST for some users but limit others to GET. You could also test against other environmental variables, like a referring page or a user’s IP address or block.

One last little bit helps the user experience. Rather than getting a “forbidden” page when authentication fails, you can bounce them to your login screen, with a redirect:

ErrorDocument 403 http://blogs.mysite.com/mt-cp.cgi?__mode=login&blog_id=###&return_url=http%3A%2F%2Fblogs.mysite.com%2Fmy_protected_blog%2F


“###” above should be the Movable Type ID number of the protected blog. That line sends them to the login screen, and when they’ve successfully logged in they are returned to the protected blog.

Your complete .htaccess file, which you’d put into the /blogroot/my_protected_blog directory (wherever that is), would look like this:

SetEnvIfNoCase Cookie mt_user=readerone readblog
SetEnvIfNoCase Cookie commenter_name=john%20doe readblog
SetEnvIfNoCase Cookie mt_user=readertwo readblog
SetEnvIfNoCase Cookie commenter_name=jane%20roe readblog
<Limit GET POST>
order deny,allow
deny from all
allow from 127.0.0.1
allow from env=readblog
</Limit>
ErrorDocument 403 http://blogs.mysite.com/mt-cp.cgi?__mode=login&blog_id=421&return_url=http%3A%2F%2Fblogs.mysite.com%2Fmy_protected_blog%2F


This is obviously not totally secure, since cookies can be forged. Don’t use this for your country’s nuclear secrets or your personal financial information. And it does require hand-editing the .htaccess file whenever you need to add users. A nice project would be to build a plugin that writes the file automatically when new users are added or deleted, but that’s for another time.