Resolved Protected directory not working for php files

[Peter Debik]

Thank you, forwarded to developers here.

 

[kpushkarev]

The problem with 18.0.59 is due to missing proxy_pass inside location blocks for protected directories, so the correct location block for a protected directory, if you have "Serve static files directly by nginx" enabled, would be like

        location ~ "^/protdir/" {
                auth_basic "Test";
                auth_basic_user_file "/var/www/vhosts/system/example.com/pd/d..httpdocs@protdir";

                location ~ ^/(.*\.(ac3|avi|bmp|bz2|css|cue|dat|doc|docx|dts|eot|exe|flv|gif|gz|htm|html|ico|img|iso|jpeg|jpg|js|mkv|mp3|mp4|mpeg|mpg|ogg|pdf|png|ppt|pptx|qt|rar|rm|svg|swf|tar|tgz|ttf|txt|wav|woff|woff2|xls|xlsx|zip|webp))$ {
                        try_files $uri @fallback;
                }
                proxy_pass https://127.0.0.1:7081;
                proxy_hide_header upgrade;
                proxy_set_header Host             $host;
                proxy_set_header X-Real-IP        $remote_addr;
                proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
                access_log off;
        }

- the second location block in the following location directive was not a good idea and is the root of all evil here:

That inner "location ~ ^/(.*\.(ac3|avi|..." block is for serving static files from protected directories. It's not at fault here.

- just remove the other location block and put the auth_basic inside the inner block

Not sure what "other location block", but the location block "location ~ "^/" {" in your example is already protected. If the request matches it, nginx will ask for authentication.

- there is another location directive for the static files at the end of the server config block (maybe copy and paste mistake, needs to be removed too)

It's not a mistake, that block is for static files in non-protected directories.

 

[Hangover2]

@kpushkarev Your solution is also one way to go. This part of the config file exists only for the option "Serve static files directly by nginx".
I would prefer the @fallback solution with only one location directive, means without the "outer one".

Here is the current buggy nginx.conf as example ("/test" is password protected via backend):

location / {
   proxy_read_timeout 300;
   proxy_pass https://127.0.0.1:7081;
   proxy_hide_header upgrade;
   proxy_set_header Host             $host;
   proxy_set_header X-Real-IP        $remote_addr;
   proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
   access_log off;
}

location ~ "^/test/" {
   auth_basic "Please login first...";
   auth_basic_user_file "/var/www/vhosts/system/example.com/pd/d..httpdocs@test";

   location ~ ^/(.*\.(ac3|avi|bmp|bz2|css|cue|dat|doc|docx|dts|eot|exe|flv|gif|gz|htm|html|ico|img|iso|jpeg|jpg|js|mkv|mp3|mp4|mpeg|mpg|ogg|pdf|png|ppt|pptx|qt|rar|rm|svg|swf|tar|tgz|ttf|txt|wav|w
off|woff2|xls|xlsx|zip|webp))$ {
      try_files $uri @fallback;
   }
}

location @fallback {
   proxy_read_timeout 300;
   proxy_pass  https://127.0.0.1:7081;
   proxy_hide_header upgrade;
   proxy_set_header Host             $host;
   proxy_set_header X-Real-IP        $remote_addr;
   proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
   access_log off;
}

location ~ ^/(.*\.(ac3|avi|bmp|bz2|css|cue|dat|doc|docx|dts|eot|exe|flv|gif|gz|htm|html|ico|img|iso|jpeg|jpg|js|mkv|mp3|mp4|mpeg|mpg|ogg|pdf|png|ppt|pptx|qt|rar|rm|svg|swf|tar|tgz|ttf|txt|wav|woff|woff
2|xls|xlsx|zip|webp))$ {
   try_files $uri @fallback;
}

I would generate it the following way for this scenario:

# Serve static files directly by nginx is enabled AND
# password protection is not on the root level
location ~* ^/test/(.*\.(ac3|avi|bmp|bz2|css|cue|dat|doc|docx|dts|eot|exe|flv|gif|gz|htm|html|ico|img|iso|jpeg|jpg|js|mkv|mp3|mp4|mpeg|mpg|ogg|pdf|png|ppt|pptx|qt|rar|rm|svg|swf|tar|tgz|ttf|txt|wav|w
off|woff2|xls|xlsx|zip|webp))$ {
   auth_basic "Please login first...";
   auth_basic_user_file "/var/www/vhosts/system/example.com/pd/d..httpdocs@test";

   try_files $uri @fallback;
}

# Serve static files directly by nginx is enabled AND
# password protection is not on the root level OR there is no password protection at all
location ~* ^/(.*\.(ac3|avi|bmp|bz2|css|cue|dat|doc|docx|dts|eot|exe|flv|gif|gz|htm|html|ico|img|iso|jpeg|jpg|js|mkv|mp3|mp4|mpeg|mpg|ogg|pdf|png|ppt|pptx|qt|rar|rm|svg|swf|tar|tgz|ttf|txt|wav|woff|woff
2|xls|xlsx|zip|webp))$ {
   try_files $uri @fallback;
}

location / {
   proxy_read_timeout 300;
   proxy_pass https://127.0.0.1:7081;
   proxy_hide_header upgrade;
   proxy_set_header Host             $host;
   proxy_set_header X-Real-IP        $remote_addr;
   proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
   access_log off;
}

location @fallback {
   proxy_read_timeout 300;
   proxy_pass  https://127.0.0.1:7081;
   proxy_hide_header upgrade;
   proxy_set_header Host             $host;
   proxy_set_header X-Real-IP        $remote_addr;
   proxy_set_header X-Forwarded-For  $proxy_add_x_forwarded_for;
   access_log off;
}

As you can see I did a small extra optimization with this bugfix. Plesk developers: please use "location ~*" including the star for the static files optimization. A lot of case sensitive files are still being processed unnecessarily by the Apache webserver. Only with the * addition files like "MyStaticFile.Txt" can be handled also by the Nginx webserver directly. This will speed up a lot of websites that are using capital letters in their static file names. Thanks in advance!

 

[Hangover2]

It's not a mistake, that block is for static files in non-protected directories.

Correct if the password protection is not on the root level as it was in my example. In my posting above I did clarify it. There is always space for optimization^^

 

[kpushkarev]

@Hangover2 Unfortunately, in general, Plesk-generated configs can become complicated depending on enabled features and installed extensions, which can give rise to unwanted interactions between directives. My solution is more error-proof in that matter, because it captures requests to protected directories early in the config and ensures authentication no matter what. At the same time, your solution would work as is, but could be thwarted by another matching regexp-location block generated later in the config, because you rely on location / and it's weaker than location ~.

 

[Hangover2]

@kpushkarev Sure, you have the full insights to the existing logic and which solution fits the best. I did only some blackbox testing to support a fast patch. But the location / I did not touch. It's the same syntax as before / current .59 release. If the location ~* optimization is not possible yet, I will make an extra bug report. But now let's hope for a quick patch first.

 

[Peter Debik]

The issue has been fixed in the latest update 18.0.59 #1, available since February 27th, 2024.

 

[Hangover2]

Unfortunately the patch doesn't work out of the box. For the ones who ended up here asking why: you will need to manually regenerate the nginx.conf files for all affected websites in one way or another. If you are not sure how to do, the Plesk repair utility for web is the way to go.

 

[kpushkarev]

If you don't have many affected domains, it could be faster to go to "Hosting & DNS -> Apache & nginx Settings" of those domains and press Apply (changing settings isn't necessary) to trigger reconfiguration.

 

[Hangover2]

For all Plesk users that want to roll-out the current release 18.0.59 #1, there is now maybe one more thing to consider.

As described in this thread, the password protection for Nginx did not work at all for at least 18.0.58 and 18.0.57. As a side effect e.g. the backends of Shopware 6 systems did work without any trouble using the built-in password protected directories (just some extra rules for the Apache .htaccess file was needed).

The backends of those websites will not work anymore after switching to 18.0.59 #1. You need to deactivate the protection in the Plesk hosting panel and include a proper user restriction via .htaccess rules.

 

[n0fear]

@Hangover2 @kpushkarev @Peter Debik thank you all for your investigations. had the problem still after update! It stills downloads php files under protected dirs! Recreating ngings settings like wrote above did the trick. But, this is a huge security bug in my opinion, why are there not more instructions than "(Plesk for Linux) PHP once again works correctly in password-protected directories. (PPPM-14334)" in the update? That alone does not fix the problem! :-/

Can i somehow see all domains / that use protected dirs?

 

[Peter Debik]

Thank you for your feedback. I've seen a similar comment before and have now asked the tech docs team to add instructions to the change log.