[SOLVED] .htaccess Is Not working in Linux (Debian) apache2 (Google Cloud)

Issue

I know this topic has been discussed to death but I still don't see directions on how to debug this problem. I know the .htaccess file is being read because I added some gibberish to it and that broke the site. I also created the .htpasswd file. The problem is that the site is not requiring a username and password. How do I go about debugging this problem?

This is what is in /etc/apache2/apache2.conf:

<Directory /var/www/>
  Options Indexes FollowSymLinks
  AllowOverride All
  Require all granted
</Directory>

This is what is in /var/www/html/.htaccess:

AuthType Basic
AuthName "Área restrita"
AuthUserFile /etc/apache2/.htpasswd
require valid-user

I don't have another vHost. This is the only virtual machine I have which is the one where the site is hosted. The DocumentRoot is specified in these files as shown below:

sites-available/000-default.conf:       DocumentRoot /var/www/html
sites-available/default-ssl.conf:       DocumentRoot /var/www/html

I placed another .htaccess file in /usr/lib/cgi-bin which is exactly the same as in /var/www/html. The purpose is to protect the perl scripts.

The URL is http://recordspreservation.org

I am also trying for now to limit access to my website with this directive. I am not sure if this has an impact on the .htaccess issue:

<Location />
    Require ip 107.217.8.189
</Location>

These are the Directory containers I found on /etc/apache2. Most of them are default (i.e. I haven't changed them). The one I may have a concern is /home/*/public_html

conf-available/gitweb.conf:               <Directory /usr/share/gitweb>
conf-available/gitweb.conf:               </Directory>
conf-available/javascript-common.conf:    <Directory "/usr/share/javascript/">
conf-available/javascript-common.conf:    </Directory>
conf-available/serve-cgi-bin.conf:        <Directory "/usr/lib/cgi-bin">
conf-available/serve-cgi-bin.conf:        </Directory>
conf-enabled/gitweb.conf:                 <Directory /usr/share/gitweb>
conf-enabled/gitweb.conf:                 </Directory>
conf-enabled/javascript-common.conf:      <Directory "/usr/share/javascript/">
conf-enabled/javascript-common.conf:      </Directory>
conf-enabled/serve-cgi-bin.conf:          <Directory "/usr/lib/cgi-bin">
conf-enabled/serve-cgi-bin.conf:          </Directory>
mods-available/alias.conf:                <Directory "/usr/share/apache2/icons">
mods-available/alias.conf:                </Directory>
mods-available/userdir.conf:              <Directory /home/*/public_html>
mods-available/userdir.conf:              </Directory>
mods-enabled/alias.conf:                  <Directory "/usr/share/apache2/icons">
mods-enabled/alias.conf:                  </Directory>
sites-available/default-ssl.conf:         <Directory /usr/lib/cgi-bin>
sites-available/default-ssl.conf:         </Directory>

The result of command sudo apachectl -M | grep auth

 auth_basic_module (shared)
 authn_core_module (shared)
 authn_file_module (shared)
 authz_core_module (shared)
 authz_host_module (shared)
 authz_user_module (shared)

Thanks!

Solution

I am also trying for now to limit access to my website with this directive. I am not sure if this has impact on the .htaccess issue:

<Location />
    Require ip 107.217.8.189
</Location>

It's not clear whether you had these directives initially or this is something you've added since, but yes, these will indeed have an "impact".

This will effectively override the HTTP authentication directives in the .htaccess file and grant access for your IP. You will not be prompted for username/password since access has been granted by other means.

<Location> sections are merged after <Directory> and .htaccess sections.

If you want to enforce both, so you (from your IP address) are prompted for username/password (and users from other IPs are simply blocked) then you can perhaps add AuthMerging And to the <Location> block (the default is Off). For example:

<Location />
    AuthMerging And
    Require ip 107.217.8.189
</Location>

This ensures the authorization logic is combined with that of the nearest predecessor. Although this does assume that the .htaccess file in question is the nearest predecessor; which it may not be.

Answered By - MrWhite

Answer Checked By - David Goodson (WPSolving Volunteer)