# Issue with HttpAuthDigestModule **URL:** \ **Category:** NGINX\ **Created:** [March 8, 2013, 5:20am UTC](https://www.ruby-forum.com/t/issue-with-httpauthdigestmodule/227238 "2013-03-08T05:20:09Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![redleaderuk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e19b73/32.png) [@redleaderuk](https://www.ruby-forum.com/u/redleaderuk)\ **Post date:** [March 8, 2013, 5:20am UTC](https://www.ruby-forum.com/t/issue-with-httpauthdigestmodule/227238/1 "2013-03-08T05:20:09Z")
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: > **[Issue with HttpAuthDigestModule](https://forum.nginx.org/read.php?2,237107,237107#msg-237107)** > > 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... ---
**Author:** ![redleaderuk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e19b73/32.png) [@redleaderuk](https://www.ruby-forum.com/u/redleaderuk)\ **Post date:** [March 9, 2013, 12:42am UTC](https://www.ruby-forum.com/t/issue-with-httpauthdigestmodule/227238/2 "2013-03-09T00:42:17Z")
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: > **[Re: Issue with HttpAuthDigestModule](https://forum.nginx.org/read.php?2,237107,237144#msg-237144)** > > 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... ---
**Author:** ![redleaderuk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/e19b73/32.png) [@redleaderuk](https://www.ruby-forum.com/u/redleaderuk)\ **Post date:** [March 9, 2013, 6:59pm UTC](https://www.ruby-forum.com/t/issue-with-httpauthdigestmodule/227238/3 "2013-03-09T18:59:20Z")
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. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)