Welcome to WebmasterWorld Guest from

Forum Moderators: Ocean10000 & phranque

Message Too Old, No Replies

WordPress rewrite and password protected directories

wordpress rewrite password protected

6:50 am on Jul 2, 2008 (gmt 0)

New User

10+ Year Member

joined:July 1, 2008
posts: 2
votes: 0


The problem: If you run WordPress from root and want to password protect some sub-directories, the default installation of WordPress makes this impossible by means of the rule WordPress inserts into .htaccess.

A default installation of WordPress adds the following lines to .htaccess:

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress

The conditions above work as intended, i.e. if your WordPress installation is in root and you want to serve static HTML pages from, letís say, /library they are served. If you type some non-existing resource in the address bar, WordPress will intercept, try to locate the resource within its own structure otherwise displaying the WordPress 404 page.

HOWEVER if you decide to password protect the directory /library the conditions do not apply. There is a good effort in explaining why and a fix over at the WordPress.org forum: [wordpress.org...]

The fix: Precede the rule in .htaccess with the following lines:

ErrorDocument 401 /path/to/onerror.html
ErrorDocument 403 /path/to/onerror.html

Where onerror.html is a blank html file.

My question (finally):

Is this a viable solution? Wouldn't it be better to have another rule for e.g. /Library that takes precedence over . /index.php [L], or is it fruitless since you cannot intercept the 401/403 response?

Any suggestions or comments are very much welcomed, thank you!

Best Regards


2:02 pm on July 2, 2008 (gmt 0)

Senior Member

WebmasterWorld Senior Member jdmorgan is a WebmasterWorld Top Contributor of All Time 10+ Year Member

joined:Mar 31, 2002
votes: 0

The proposed solution has several faults, not the least of which is the suggestion to make the error documents blank -- This is a horrible usability problem in the making. Error documents should describe the error in simple terms, and tell the user what to do!

Password-protection is always difficult to debug, and I don't have a site set up like this, nor time to test it. But I'd recommend doing it like this:

In /.htacess:

RewriteEngine on
# BEGIN WordPress (modified)
# If requested URL-path does not start with "/library/"
RewriteCond %{REQUEST_URI} !^/library/
# and requested URL_path does not resolve to existing file
RewriteCond %{REQUEST_FILENAME} !-f
# and requested URL-path does not resolve to existing directory
RewriteCond %{REQUEST_FILENAME} !-d
# rewrite the request to WordPress
RewriteRule . /index.php [L]
# END WordPress

Note that I deleted the <IfModule> container and the RewriteBase directive -- Neither are needed. <IfModule> guarantees a 'silent failure' on a server where mod_rewrite is not available, so if you've got mod_rewrite on your server, don't bother wasting CPU time executing <IfModule>. "RewriteBase /" is the default setting, so there is no need to execute that, either.

Then add your password-protection code to example.com/library/.htaccess *and* declare a 401 ErrorDocument in that subdirectory as well:

ErrorDocument 401 /library/error-401.html

This errordocument should contain a message that says something like, "Login required. If you do not have an account, please sign up to get one and then try again. Thank you!" -- Nice tone, tell the user what to do.

The new password-protection and errordocument code placed in /library/.htaccess will only apply to requests for that subdirectory, so interaction with WP shouldn't be a problem.

I'd also recommend adding error documents in /library and corresponding error pages for at least the following error conditions, in addition to 401-Authorization required:

400-Bad request (The server could not understand the request)
403-Forbidden (Access to the requested page is not allowed)
404-Not Found (Page is missing, reason is unknown, page may return later)
410-Gone (Page was intentionally removed, and will not return)
500-Server Error (Server is likely mis-configured, please try again later)

Note that many sites' functional problems and poor search engine ranking problems are caused by incomplete and/or incorrect server configuration -- It pays to be thorough in both configuration and testing!

One more note: While testing, I recommend that you completely flush your browser cache before testing any new changes to your code -- Stale cached server responses can cause a lot of problems and confusion in testing!


9:32 pm on July 2, 2008 (gmt 0)

New User

10+ Year Member

joined:July 1, 2008
posts: 2
votes: 0

Thank you ever so much for your prompt, exhaustive and most importantly accurate answer!

Your suggestions do indeed solve the problem.

Some findings:

  • Apache serves /library and the corresponding authentication prompt even if the new condition: RewriteCond %{REQUEST_URI} !^/library/ is left out. Thus it seems as if itís the specification and creation of the error-401.html file that does the trick. Or is the condition necessary for some other reason?

  • The custom error page (error-401.html) does not display. I get "Additionally, a 401 Authorization Required error was encountered while trying to use an ErrorDocument to handle the request."

Of-course if I place the error-401.html file in another, not password protected, directory and specify it in /library/.htaccess it displays nicely, but is that necessary?

Thanks in advance!

Best Regards


7:45 am on July 5, 2008 (gmt 0)

New User

10+ Year Member

joined:July 5, 2008
posts: 1
votes: 0

Thanks to both of you. This solved a problem I had a while back, and just encountered again today. So - TWO PROBLEMS SOLVED. ;-)

Apparently here is what happens:

When checking if a destination exists,
* And if an .htaccess doc exists there
* And if it requires authentication

then the authentication cannot proceed,
and we are sent to WordPress's default 403 behaviour.

Simply by declaring and creating a valid 401 document
*not in* the protected directory, *then* the 'protected
directory' behavior works with the Wordpress code.

To summarize what I've done - and believe to be the minimal implementation:

I created 2 files:


If you have been granted access,
you will have an email with user
and password details.


ErrorDocument 401 /Forms/401.html
AuthType Basic
AuthName "Paid Member"
AuthUserFile "/home/acct/.htpasswds/public_html/protected-dir/passwd"
require valid-user


[edited by: jdMorgan at 4:33 pm (utc) on July 5, 2008]
[edit reason] No URLs, please -- See TOS. [/edit]