{"id":116,"date":"2006-08-15T23:27:06","date_gmt":"2006-08-16T03:27:06","guid":{"rendered":"http:\/\/unitstep.net\/blog\/2006\/08\/15\/wordpress-and-password-protected-directories\/"},"modified":"2006-08-30T11:34:49","modified_gmt":"2006-08-30T15:34:49","slug":"wordpress-and-password-protected-directories","status":"publish","type":"post","link":"https:\/\/unitstep.net\/blog\/2006\/08\/15\/wordpress-and-password-protected-directories\/","title":{"rendered":"WordPress and password-protected directories: How to make them work together"},"content":{"rendered":"

If you have WordPress installed in the root directory of your website, as many people do, then the entire website is subject to the .htaccess<\/code> rules defined by WordPress, if you’re using a permalink structure that uses mod_rewrite<\/code>. (Again, most people use this option, as it allows for human-readable URIs instead of ones filled with GET queries) Because the WordPress .htaccess<\/code> file resides in the site root folder, it allows WordPress to handle all URIs relating to requests from the site – this is good, as it allows WordPress to handle 404s nicely, and you can define 404 pages from within WordPress rather than having to resort to server directives.<\/p>\n

However, this can create problems if you want to create password-protected directories. Accessing them sometimes doesn’t work because of WordPress’s .htaccess<\/code> file, however this isn’t a WordPress problem per se<\/i>, but rather a problem with how Apache has been set up. I ran into this problem – I tried accessing a password-protected directory that I knew had been set up properly, but I kept getting a 404 error and was redirected to my WordPress theme’s 404 page. After a little bit of searching over at the WordPress support boards<\/a>, I found some solutions that were sort of messy, involving editing WordPress files or adding a lot to the .htaccess<\/code> file.
\n
\nHowever, after looking for a bit more, I found this page<\/a>, where the author outlines his fix; but later on a comment posted to his site provided me with the fix I wanted – something simple<\/a>. Though that site deals with TextPattern<\/a>, another blogging platform, apparently it handles requests in a similar manner to WordPress.<\/p>\n

The problem lies with improperly set (usually non-specified) ErrorDocument<\/code> directives. In this case, the responsible error codes are 401<\/a> (Unauthorized) and 403<\/a> (Forbidden). These directives are used to tell Apache what document to send or display to the user when each of these error codes are encountered. If these are set to point to a non-existant file, WordPress ends up handling the request – which in these cases, it treats just like a 404. When you try to access a password-protected resource, Apache first sends a 401 (Unauthorized), as a challenge to provide the proper credentials (login\/password); if the error directive for this points to non-existant file, then the request is improperly passed on to WordPress and then treated like a 404 here.<\/p>\n

To fix it, you need to specify the error directives in your root .htaccess<\/code> file, which if you have WordPress in the root, is the same file that WordPress uses. If you open it up, you should find WordPress’ rules in there, which will look something like this<\/p>\n

# BEGIN WordPress\r\n<ifmodule mod_rewrite.c>\r\nRewriteEngine On\r\nRewriteBase \/\r\nRewriteCond %{REQUEST_FILENAME} !-f\r\nRewriteCond %{REQUEST_FILENAME} !-d\r\nRewriteRule . \/index.php [L]\r\n<\/ifmodule>\r\n# END WordPress<\/code><\/pre>\n
Add the following lines to the .htaccess<\/code> file.<\/p>\n
ErrorDocument 401 \/<PATH_TO_ERROR_DOCS>\/401.html\r\nErrorDocument 403 \/<PATH_TO_ERROR_DOCS>\/403.html<\/code><\/pre>\n
Where 401.html and 403.html are the pages you want shown when each of those respective errors are encountered.  These should be static pages. (eg. not server-side scripts)  This fix worked like a charm for me.  <\/p>","protected":false},"excerpt":{"rendered":"
If you have WordPress installed in the root directory of your website, as many people do, then the entire website is subject to the .htaccess rules defined by WordPress, if you’re using a permalink structure that uses mod_rewrite. (Again, most people use this option, as it allows for human-readable URIs instead of ones filled with […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[77,79,78,25],"tags":[],"_links":{"self":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts\/116"}],"collection":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/comments?post=116"}],"version-history":[{"count":0,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/posts\/116\/revisions"}],"wp:attachment":[{"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/media?parent=116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/categories?post=116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unitstep.net\/wp-json\/wp\/v2\/tags?post=116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}