Issue with HttpAuthDigestModule

Server NGINX
1

Hello Nginx people!

I hope you can help me. I’m having an infuriating problem with auth
digest
via the HttpAuthDigestModule.

The first site I added to Nginx used the same htdigest password file as
my
Apache webserver (on the same box) uses. This works fine. However, I
added
a second website that uses an almost identical configuration but for
some
reason I simply cannot authenticate for this second site. I’m using the
same htdigest password file, same username and password. The first
website
I can authenticate, the second one refuses to authenticate me. I can’t
figure out why!

Here is the first website’s conf file:
#########

Project 1 configuration

upstream project1_backend {
server unix:/var/www/project_1/tmp/php.sock;
}

server {
listen 8083;
server_name dev.project_1.site.com;
root /var/www/project_1/web;

access_log /var/www/project_1/logs/nginx_access.log;
error_log /var/www/project_1/logs/nginx_error.log;

# strip app.php/ prefix if it is present
rewrite ^/app\.php/?(.*)$ /$1 permanent;

auth_digest_user_file /etc/apache-digest-passwd;

location / {
auth_digest 'my-realm';
index app.php;
    try_files $uri @rewriteapp;
}

location @rewriteapp {
    rewrite ^(.*)$ /app.php/$1 last;
}

# pass the PHP scripts to FastCGI server listening on php socket
location ~ ^/(app|app_dev|config)\.php(/|$) {
    fastcgi_pass project1_backend;
    fastcgi_split_path_info ^(.+\.php)(/.*)$;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME

$document_root$fastcgi_script_name;
fastcgi_param HTTPS off;
}
}
#########

The second configuration file looks like this:
#########

Project 2 configuration file

upstream project2_backend {
server unix:/var/www/project_2/tmp/php.sock;
}

server {
listen 8083;

server_name project_2.site.com;
root /var/www/project_2/web;

access_log /var/www/project_2/logs/nginx_access.log;
error_log /var/www/project_2/logs/nginx_error.log error;

# strip app.php/ prefix if it is present
rewrite ^/app\.php/?(.*)$ /$1 permanent;

auth_digest_user_file /etc/apache-digest-passwd;

location / {
auth_digest 'my-realm';
index app.php;
    try_files $uri @rewriteapp;
}

location @rewriteapp {
    rewrite ^(.*)$ /app.php/$1 last;
}

# pass the PHP scripts to FastCGI server listening on php socket
# REMOVE config from choices on PRODUCTION!
location ~ ^/(app|app_dev|config)\.php(/|$) {
    fastcgi_pass project2_backend;
    fastcgi_split_path_info ^(.+\.php)(/.*)$;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME

$document_root$fastcgi_script_name;
fastcgi_param HTTPS off;
}
}
#########

I’ve tried creating a new password file with htdigest and adding a
user/password to it, then referencing that new password file in the
second
website’s conf file but I still can’t authenticate.

Can anyone shed some light on this for me please?

Thanks for any help you can offer,

Alex

Posted at Nginx Forum:

2

I think I’ve found the actual problem: having a querystring at the end
of
the URL stops the HttpAuthDigiestModule from working correctly.

In fact, simply appending a question mark at the end of a URL is enough
to
prevent authentication. I just get repeatedly asked to authenticate,
round
and round I go in a loop.

Can anyone shed any light on this please? I hope it’s something I can
fix
via the config file but perhaps it’s simply a limitation with the module
itself?

Posted at Nginx Forum:

3

On Fri, Mar 08, 2013 at 06:41:46PM -0500, redleaderuk wrote:

Hi there,

I think I’ve found the actual problem: having a querystring at the end of
the URL stops the HttpAuthDigiestModule from working correctly.

Can anyone shed any light on this please? I hope it’s something I can fix
via the config file but perhaps it’s simply a limitation with the module
itself?

It looks to me like a problem with this third-party module.

It calculates a hash over r->uri, and compares it with the hash that the
browser calculated over its idea of the request. If you replace r->uri
with r->unparsed_uri and recompile, it will work for more requests.

The “right” fix is probably to use fields->uri instead, and then also
make sure that fields->uri and r->unparsed_uri correspond to the same
thing. That (in theory) should work for all requests, but would also
take longer to do right.

f

Francis D. [email protected]