I have an nginx server block to proxy_pass content from three servers: gitlab, Rshiny and static content from another nginx server block. All this works fine, until I try to add password protection to one of the directories in my static content site. I have the following configuration:
The location block for the proxy:
location /project_builds/ {
rewrite ^/project_builds/(.*)$ /$1 break;
proxy_pass http://localhost:8000;
proxy_redirect http://localhost:8000/ $scheme://$host/project_builds/;
}
The server block for the static page:
server {
listen 8000;
server_name localhost;
location / {
root /web/project_builds/;
index index.html;
autoindex on;
}
location /campy_SAM {
auth_basic "Restricted content";
auth_basic_user_file /web/password_files/campy_SAM/.htpasswd;
}
}
The result of this configuration is that the root material of the static site is displayed fine in to the proxy location and a username and password are requested for the sub-directory of the static page as I expect. However, when I supply the correct username and password I get the '404 Not Found' page. When I comment out the two 'auth_basic' lines in the config, the content in the sub-directory is displayed fine.
Am I missing something in the location block for the proxy to make the password authentication work properly?
the logs from the server:
error.log (wrong password)
2014/06/27 16:55:23 [error] 30504#0: *64 user "campy_SAM": password mismatch, client: 127.0.0.1, server: localhost, request: "GET /campy_SAM/project_page.html HTTP/1.0", host: "localhost:8000", referrer: "http://********************/project_builds/"
error.log (correct password)
2014/06/27 16:55:56 [error] 30504#0: *67 open() "/usr/share/nginx/html/campy_SAM/project_page.html" failed (2: No such file or directory), client: 127.0.0.1, server: localhost, request: "GET /campy_SAM/project_page.html HTTP/1.0", host: "localhost:8000", referrer: "http://*****************/project_builds/"
Best Answer
I solved this one from the suggestion of posting the nginx logs. I guess it's always a good idea to carefully inspect the logs. I made the mistake of placing the root inside the first location block of the server. Therefore when I navigated to the subdirectory it mapped the incorrect location. The following configuration makes it work the way I expect:
}
It is still curious that it worked when I removed the authentication, with the root inside the first location block.... I can probably live without understanding why that is :)