Using permalinks can prevent access to password protected folders.

[Bassetts]

When permalinks are enabled from the admin interface it prevents access to a password protected folder within the root directory and supplies a 404.

I have found that a way to fix this would be to add the following lines before the wordpress part of the .htaccess:

ErrorDocument 401 /secure/
ErrorDocument 403 /secure/

Changing /secure/ to the name of the folder that access is required for. This could be implemented into the admin interface in the style of a few text boxes where folder names can be inserted and the interface generates the lines necessary to allow access to the folder.

[Otto42]

This has to do with the way .htaccess works in this unusual situation.

Actually, those "ErrorDocument" lines don't need to point to the folder in question. They simply need to point to any file which actually exists.

.htaccess files are additive. Whenever you request a page, the webserver basically goes through every directory down the tree from the root (specified by the closest match of <Directory ...> in the httpd.conf file), and adds all the .htaccess files together. As it traverses them, it parses each one. Later .htaccess files override previous ones, but only for the same specified items. RewriteRules are cumulative.

So what is going on is that the authorization in the password protected directory is forcing a 401 response ("Authorization Required") back to the client. Normally, the client would get the 401 and ask for a password.

However, in this case, this 401 response is intercepted by the Wordpress RewriteRules which says to rewrite everything to Wordpress. This is because .htaccess's are cumulative and your closest matching Directory is the root.

So, by forcing an ErrorDocument for the 401 response before the Wordpress rules, you pre-empt them (since the file actually exists, the RewriteRules won't take effect upon it due to the -f, or -d in the above case), causing your 401 document to be sent instead of rewriting to Wordpress. However, the client doesn't care about that document, it sees the 401 and asks for a password.

The 403 line will cause it to send back a forbidden message on password entry failure. If you leave that off, the client actually will get redirected back to Wordpress in that case.

Other possible solutions are:

• Add a new Directory statement to httpd.conf, specifically specifying your password protected directory, thus bypassing the wordpress rewrites from the htaccess search path.
• Add another rewrite to the top of the wordpress rewrites that pre-empts them for that directory only.

Forcing a 401/403 ErrorDocument seems like the best solution to me, since it will work with any password protected subdirectories you care to add, without having to specify them.

Or perhaps Wordpress itself can recognize the 401/403 response when it starts and exit early to eliminate this problem, although that may cause other problems.

But this problem has existed for a long time, it only affects a small number of users, and it exists for other packages that use the RewriteRule . index.php type of rewrites as well. It's a combination of circumstances, not a critical flaw.

[foolswisdom]

Closing as won't fix for now.