Htaccess Require expr Apache 2.4 works on osx-sierra not on debian-jessie

Question

On my development machine osx-sierra / apache 2.4.10 (from brew) I have a restriction in a VirtualHost that allow access to /api/ without password, and all others pages need the password with this code:

<Location />
    AuthType Basic
    AuthName "Access"
    AuthUserFile /Users/xxxxxx/www/public/.htpasswd
    Require expr %{REQUEST_URI} =~ m#^/api/*#
    Require valid-user
</Location>

When I try to do it on my production server with the same directives, Debian-jessie / apache 2.4.29 (from apt), it doesn't work, password is always ask (chrome/safari/wget), I tryed theses solutions :

1/

<Location />
    AuthType Basic
    AuthName "Access"
    AuthUserFile /home/xxxxxx/www/public/.htpasswd
    Require expr %{REQUEST_URI} =~ m#^/api/*#
    Require valid-user
</Location>

2/

<Location />
    AuthType Basic
    AuthName "Access"
    AuthUserFile /home/xxxxxx/www/public/.htpasswd
    Require expr %{REQUEST_URI} =~ m#^/api/.*#
    Require valid-user
</Location>

Any idea of why these differences ?

Thanks

Answer 1

I'm not sure why that would work on osx-sierra / Apache 2.4.10, but not seemingly on Debian-jessie / Apache 2.4.29. However, as a workaround you could do this a different way using a negative lookahead on a <LocationMatch> container instead of using Apache 2.4 expressions. For example:

<LocationMatch "^(?!/api/.*$).*$">
    AuthType Basic
    AuthName "Access"
    AuthUserFile /Users/xxxxxx/www/public/.htpasswd
    Require valid-user
</LocationMatch>

Now, the directives inside the <LocationMatch> container are only processed when the URL does not start /api/. (This also works on Apache 2.2)

Answer 2

This is the complet virtualhost where directives do not work :

<VirtualHost *:80>
DocumentRoot /home/xxxxxx/www/public
ServerName xxxxxx.com

Header set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, PUT, GET, DELETE, OPTIONS"
Header always set Access-Control-Allow-Headers "x-so-resource, x-so-apikey, x-so-apisecret, x-token, Authorization, Content-Type"

<Directory /home/xxxxxx/www/public>
    php_value include_path "/home/xxxxxx/libs/ZendFramework-1.11.11/library"
    Options +FollowSymLinks 
    AllowOverride All
    Order allow,deny
    Allow from all
    Require all granted
</Directory>

ServerSignature Off

AddDefaultCharset UTF-8

php_value short_open_tag 0

SetEnv APPLICATION_ENV development


<Location />
    RewriteEngine On     
    RewriteCond %{REQUEST_FILENAME} -s [OR]
    RewriteCond %{REQUEST_FILENAME} -l [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^.*$ - [NC,L]
    RewriteRule ^.*$ index.php [NC,L]
</Location>


<LocationMatch "^(?!/api/.*$).*$">
    AuthType Basic
    AuthName "Access"
    AuthUserFile /home/xxxxxx/www/public/.htpasswd
    Require valid-user
</LocationMatch>

ErrorLog /var/log/apache2/xxxxxxxx-error.log
CustomLog /var/log/apache2/xxxxxxxx-access.log combined

Answer 3

Why complicate it so much instead of doing it straightforward?

<Location />
    AuthType Basic
    AuthName "Access"
    AuthUserFile /home/xxxxxx/www/public/.htpasswd
    Require valid-user
</Location>

<Location /api>
        Require all granted
</Location>

Also note, your previous Directory (the documentroot directory) directive mixing 2.2.x and 2.4.x directives could be screwing everything up.

A mess:

Order allow,deny
Allow from all
Require all granted

The correct thing to do:

Require all granted

• Be sure to remove 2.2. directives and unload mod_access_compat to be sure, what you do is a recipe for getting unexpected results. Also consider .htaccess files you may have could be affecting the result due to setting AllowOverride all, which ideally you shouldn't use if you are the admin of the site.