I tried to make a password protected directory using a .htaccess file earlier today and found out that the root WordPress .htaccess file causes a little trouble.
The situation looks something like:
- /
- .htaccess <- From WordPress
- /ProtectedDir
- .htaccess <- My file
As of WordPress 2.3.2, its .htaccess file looks like this:
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress
This lives at the base of WordPress install, which for me happens to be the root of my web site. The rewrite rule throws any URL that leads to a non-existent file to WordPress’ index.php. This lets WordPress do search engine friendly URLs and custom 404 handling.
The problem here is subtle. In order to do password authentication, the web server needs to serve up a “401 Unauthorized” header and optionally an error document. My server defaults to a specific error document path, but I have not created a document at that path. However, Apache still passes the predefined 401 document path through the rewrite rules in an attempt to use it. Since it doesn’t exist, the request gets snagged by the WordPress rewrite rules and index.php. The end result is that what should have been a 401 page now turns into a 404 and you can’t authenticate to the directory.
The solution is simple: override the non-existent, predefined error document path using the ErrorDocument directive in either of the .htaccess files mentioned above.
You have several options. You can either use Apache’s default hard-coded string for the error document by specifying:
ErrorDocument 401 default
Or you can use your own hard-coded error string:
ErrorDocument 401 "Unauthorized access"
Or you can create a 401 document and point the server to it like so:
ErrorDocument 401 /401.html
Pick one of those methods and your password authentication should work. Remember, the error document file must exist if you pick the last method.
Note that the same problem can occur with other HTTP error codes, so be on the lookout for other situations where WordPress might bite you.
Updated Jan. 27 thanks to a suggestion made in this web forum post.
Excellent fix
I was up until 3.00 in the am trying to figure this out and now in about 1 minute thanks to you I got it to work properly.
Thanks for posting this!!
*THANK YOU* I was going crazy trying to figure out why a “nested” wordpress blog wasn’t working when password protected.
Brilliant, thanks! At first I thought it didn’t work because I tried the first option and nothing changed. But then I realized, what if there is no default 401 error document specified on my server or in my WP installation somehow? So I used the second option above, and bingo. Thanks!
thankyou so much !!! this was hell trying to figure out and the second option worked first go!
hurrah good man
[...] LINK: Stop URL rewrite by WordPress for password protected directories. [...]
Worked great, I’m been pulling my hair out all night over this. Thank you. For the record i used the second option: ErrorDocument 401 “Unauthorized access”
You are my new hero! Thank you so, so much! That easy fix and for the wonderful explanation. Your explanation is very clear and I really appreciate it having the ‘why’ and solution. Again thank you!
I can only echo the previous comments. You bloody hero, you! May good things come your way and bad things pass you by!
So simple and obvious when you know how. Thanks for posting this fix.
Here’s another cheers, that problem was driving me crazy.
Thanks, this was GREAT!
THANKS – searching for fix like this for SO LONG! Almost gone crazy.
I’m not running a wordpress site, but I added a rewriterule to the htaccess file of the parent directory of a site that proceeded to disable the login prompt on an htaccess-protected sub-directory. I just spent 4 hours messing with the htaccess and httpd.config files trying to figure out what went wrong… As it turned out the rewriterule was affecting the custom 401 document I had setup in the htaccess file (i.e. the parent .htaccess file looked like:
RewriteCond %{REQUEST_URI} ^/~userdirectory(.*)
RewriteRule ^(.*)$ http://www.mysite.com%1 [L]
ErrorDocument 404 /~userdirectory/404.php
ErrorDocument 401 /~userdirectory/401.php
)
When the protected directory attempted to go to the 401 page the rewrite rule would skip the intervene, serving the 401.php page-content but apparently not the 401 header. Anyway, it’s not exactly the same thing as you discuss here, but your observation that the 401 header needed to be served in order to initiate authentication is what tipped me off to the problem.
Bottom line: You’re a saint!
tnx a million!
Thank you Andrew!
Like a few others mentioned above, problem was bothering me for quite awhile as well. Fixed and working as intended now.
Kudos!
Andrew
Thank you so, so much!
I had similiar problem with Joomla! password protected directory.
The solution is simple and brilliant and works in Joomla too.
Excellent work!
[...] ErrorDocument 401 default to either of the 2 .htaccess I found the solution here : WordPress and .htaccess Password Protected Directories Andrew Rollins [...]
I also tried the second option, ErrorDocument 401 "Unauthorized access" & it works fine. Thanks & keep posting
Thank you sooooo much!
Option two worked super sweet for me
Brilliant! I tried just about everything to figure out how to sort through this issue. Option 2 was what worked for me as well.
VIOLA! GENIOUS!!
Thank you sooooo much!
I had similiar problem with Joomla! password protected directory.
The solution is simple and brilliant and works in Joomla too.
Thank you so, so much!