Results 1 to 8 of 8

Thread: Protecting directory

  1. #1
    Join Date
    Nov 2015
    Posts
    80

    Protecting directory

    I'm using DirectAdmin with CB2 with Nginx-only.
    As known, it is possible to protect a directory from within the DA File Manager.

    I thought this was working perfectly, I get the HTTP-Auth screen when I visit domain.com/protected/.
    But only recently I discovered all the images inside that directory are open to the public. Directly linking to domain.com/protected/image.jpg shows the image without the need to log in.

    Is this a bug, or are additional measures needed to make it work in Nginx and did I miss that info?

  2. #2
    Join Date
    Sep 2015
    Location
    Arnhem, NL
    Posts
    366
    Can you show us the nginx rule created by DA? Somewhere in nginx.conf or included as a file.

  3. #3
    Join Date
    Nov 2015
    Posts
    80
    Ofcourse. The template that is used (nginx_protected_directory.conf) looks like this:

    Code:
    location |PROTECTED_PATH|/
    	{
    |CUSTOM2|
    |LOCATION_INSERT|
    		auth_basic		"|AUTH_NAME|";
    		auth_basic_user_file	|HTPASSWD|;
    		
    		|NGINX_PHP_CONF|
    	}
    So that turns out to this in the nginx.conf file:

    Code:
    location /protected/
    	{
    		auth_basic		"This is protected";
    		auth_basic_user_file	/path/to/the/.htpasswd;
    		include /path/to/nginx_php.conf;
    	}

  4. #4
    Join Date
    Sep 2015
    Location
    Arnhem, NL
    Posts
    366
    The location / is not enough because that only applies to one URI and is not recursively, you need something like:

    Code:
    location ^~ /folder_that_you_like_to_protect {
    Can you try this?

  5. #5
    Join Date
    Nov 2015
    Posts
    80
    Seems to work, thank you very much.

  6. #6
    Join Date
    Sep 2015
    Location
    Arnhem, NL
    Posts
    366
    This is probably something DA needs to fix in the default templates.. Because you expect that everything(every file & folder) in the directory you protect is protected.. which it isn't.

  7. #7
    Thanks for the report.

    However.. I've just tested it here, but with a fresh browser, no previous login, I access a png file, either in the /newprotect/logo.png or /newprotect/subprotect/logo.png, but both give a password popup.
    Part of the confusion I've run into in the past is the browser always remembers the login/password until you fully close that browser, then it will ask again (even if it's pre-filled).

    So unless our setups are fully different, eg mine has:
    Code:
            location /newprotect/
            {
                    auth_basic              "Gandalf";
                    auth_basic_user_file    /home/admin/domains/test-es5-64.com/.htpasswd/public_html/newprotect/.htpasswd;
                    ....
            }
    So to confirm if a User/pass is being sent to nginx, please check in your nginx logs:
    Code:
    /var/log/nginx/domains/domain.com.log
    where we'd be looking for one of these two:
    Code:
    192.168.1.6 - - [11/May/2018:16:47:49 -0600] "GET /newprotect/subprotect/logo.png HTTP/1.1" 401 590
    OR
    192.168.1.6 - balrog [11/May/2018:16:55:30 -0600] "GET /newprotect/subprotect/logo.png HTTP/1.1" 200 9292 "-" "Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36"
    just as example, where the browser would be passing the user/pass in the 2nd request, which is logged after the first dash - character (login is balrog). Also note the 200 code vs the 401 unauth code.


    If you see the 1st example where there is no login, and can you access the file (confirm in the logs, not the browser which may show a cache).. while using a fully closed and fully re-opened browser, where there is no login name, then let me know and we can add in the ^~ to the default protected template. In my tests, I wasn't able to duplicate it, plus the examples right in the nginx documentation imply that the ^~ shouldn't be required. Note that we do use a trailing slash in the name, eg "/protected/" and not "/protected" which may apply to the ^~ version:
    https://docs.nginx.com/nginx/admin-g...uthentication/

    John

  8. #8
    Join Date
    Nov 2015
    Posts
    80
    Thanks John for the quick support.

    Strange but no, without ^~ I can defenitely access all the .jpg's inside a protected folder without a password prompt. This is indeed tested in browsers with all history and local storage cleared. In my case it's domain.com/protected/subfolder/picture.jpg. With ^~ added it is protected.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •