Link from a Wordpress page to a password protected non-Wordpress page on a subdirectory

Question

I have a Wordpress site which contains a link to a non-WordPress (i.e. pure Html) page sitting on a subdirectory of the same domain. It all works fine at the moment but now I wish to password protect that subdirectory.

I tried adding .htaccess and .htpasswd files but then when I attempt to go to that page, instead of seeing the expected "please type a username and password" I see "This page doesn't seem to exist."

I know there are ways of adding passwords from one WordPress page to another but this issue is from WordPress to non-WordPress.

EDIT: As requested... the root directory contains the following four subdirectories:

• wp-content
• wp-includes
• wp-admin
• info

There is a link on the front page of the wordpress site like so:

Take a look at the results <a href="http://www.example.com/info/results.htm">here</a>

I put both the .htaccess and .htpasswd files in the "info" directory. The info directory also contains "results.htm" of course.

The \info\.htaccess file contains:

AuthType Basic
AuthName "Password Protected Area"
AuthUserFile /home2/public_html/example/info/.htpasswd
Require valid-user
Options -Indexes

the root .htaccess contains:

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

# END WordPress 

If I temporarily disable the root .htaccess file by renaming it then the whole thing works. I.e. I do see the request for username and password when I try and access the /info/results.htm file.

Answer 1

From the information given, this "should" work as intended. Whether the directory is protected by HTTP Authentication in this way should not matter.

I see "This page doesn't seem to exist."

I'm assuming this is a WordPress generated 404 page.

So, when the directory is "protected", it appears to be incorrectly routed through WordPress. This implies that the condition RewriteCond %{REQUEST_FILENAME} !-f in the parent .htaccess file is failing for some reason. This condition checks that the request does not map to a physical file before routing the request through WordPress. It "should not" matter that the directory where the file is located is protected by HTTP Authentication, since this filesystem check is not (or should not be) an HTTP request.

As a "workaround" you can try disabling the rewrite engine in the /info/.htaccess file. This prevents the mod_rewrite directives in the parent .htaccess file (the WordPress front-controller) from being processed.

For example:

# Prevent mod_rewrite directives in parent .htaccess file(s) being processed
RewriteEngine Off

Options -Indexes

AuthType Basic
AuthName "Password Protected Area"
AuthUserFile /home2/public_html/example/info/.htpasswd
Require valid-user

UPDATE#1: Sadly it didn't work. Still got the "This page doesn't seem to exist." message ... which by the way appeared to be WordPress generated

Try the following instead:

1. Remove the RewriteEngine directive added above in the /info/.htaccess file.

2. Add the following directives to the root .htaccess file before the # BEGIN WordPress code block:

   # Ignore any requests to the /info/ subdirectory
   RewriteRule ^info/ - [L]
   

   As the code comment states, this should now explicitly ignore any requests to the /info subdirectory. The WordPress directives that follow will not be processed so WordPress will not be invoked.

UPDATE#2: "RewriteRule ^ - [L]" works perfectly

In order to diagnose the URL-path that mod_rewrite is seeing when requesting /info/results.htm (when the directory is password protected) you can try adding the following before the above modified directive. For example:

# Debugging URL-path
RewriteCond %{QUERY_STRING} !^UrlPath=
RewriteRule (.*) /xyz?UrlPath=$1 [R,L]

# Ignore everything... (prevents URL being routed through WP)
RewriteRule ^ - [L]

When you request /info/results.htm you should^*1 now be redirected to /xyz?UrlPath=<something>. What is the <something> part? (NB: /xyz doesn't exist, so you should see an Apache 404 response - not a WordPress 404 response.)

^{(*1 - I say "should", this is on your system, with how it appears to be behaving. It "should" display the user/pwd dialog, but that is not happening for reasons not yet determined.)}