Facebook
Twitter
-
If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
CentOS2Alma discussion
Resolved Protected directory not working for php files
- Thread starter ccserv
- Start date
-
- Tags
- protected directory
How is the protected directory created? Using the built-in password-protected directories feature in Plesk? Or an .htaccess/.htpasswd file mechanism?
A bug is unlikely, but the problem could be that the session remembers you as an authorized user and lets you access the file for that reason. Could you please try it on a browser where the same (protected) PHP file was not accessed before and where you did not login to your webspace control panel or with the user who is allowed to access the file?
I did tried this. Als tried another location with diferent PC. Also tried Incognito option, used VPN with diferent IP address, all did not work.
You can try it if you want, i created testing as a protected directory: https://detestsite.nl/testing/file1.html and Untitled
You can try it if you want, i created testing as a protected directory: https://detestsite.nl/testing/file1.html and Untitled
What PHP interface has been selected (type and gateway)?
I am now treating this as a bug report and have forwarded a case to developers for further analysis. Internal ID PPS-15620.
We were unable to recreate the case with the information provided here.
The test engineer suggests that you please recreate the directory, that is password-protected, entirely. Meaning: Delete directory, delete password-account, then recreate the directory and also recreate the password protection on it, then please test again.
If this does not help, please contact Plesk support by ticket with reference to PPS-15620, so that an engineer can check the case directly on your server.
The test engineer suggests that you please recreate the directory, that is password-protected, entirely. Meaning: Delete directory, delete password-account, then recreate the directory and also recreate the password protection on it, then please test again.
If this does not help, please contact Plesk support by ticket with reference to PPS-15620, so that an engineer can check the case directly on your server.
Hi there!
Just adding some steps since Im having kind of the same issue.
I reproduce those steps on 2 different servers, got the same result. Both after updating to latest Plesk version (18.0.59)
As an additional note, if I try to access the index.php file under the random folder after authentication, the browser will try to download the file instead, like if PHP is not supported. This behavior only occurs for the protected folder, on the root folder (httpdocs) I have a WP application running with no issues.
As per PHP version and handler:
is this useful?
Just adding some steps since Im having kind of the same issue.
- Create random directory ("testing" in my case)
- Create index.php file with random content (Something like "Testing File" in my case) inside random directory
- Try to access random directory. Result: Im able to successfully see the content (Text "Testing File")
- Add protection using Plesk "Protected Directory" feature to random folder
- Try to access the random folder again (using different browser or incognito browser). Result: Authenticate and then 403 error.
I reproduce those steps on 2 different servers, got the same result. Both after updating to latest Plesk version (18.0.59)
As an additional note, if I try to access the index.php file under the random folder after authentication, the browser will try to download the file instead, like if PHP is not supported. This behavior only occurs for the protected folder, on the root folder (httpdocs) I have a WP application running with no issues.
As per PHP version and handler:
- Site #1: Ubuntu 18.04.6 LTS - PHP 8.1.27 - FPM application served by Apache
- Site #2: Ubuntu 22.04.4 LTS - PHP 8.2.16 - FPM application served by nginx
is this useful?
with the last Version (18.0.59). on the same OS Ubuntu 22.04. and the same error or download (just like @Jan Perez)
for me it is even stranger! Updated to latest version. Have a directory that is htaccess protected. today tool insdie did not work anymore. i just found out when adding a phpinfo.php file inside, that it is NOT executed inside the protected diretory after addming credentials but it is DOWNLOADED.... removing the protecttion everything works again and the phpinfofile is executed. Ubuntu 22.04.4 with dedicated php 8.2 served by apache
Hangover2
Regular Pleskian
We did investigate the mentioned problems deeper. Actually we are talking about two different problems, depending on your Plesk version in use.
We checked some of our "older" Plesk servers with Plesk versions 18.0.58.2 and 18.0.57.3.
And one test server with the latest 18.0.59.
For versions 18.0.58.2 and 18.0.57.3 the password protection via the build-in Plesk functionality fails with the following settings:
- activate "Serve static files directly by nginx" (Proxy mode enabled too)
- activate password protection for the whole domain (via hosting dashboard)
- put some files like test.txt and test.php in your public folder
- call the files directly
- password protection is not triggered
The reason can be found in the wrongly generated nginx.conf file for the domain under /var/www/vhosts/system/*:
- the auth_basic directive is missing completely for the requests Nginx is handling alone
- so static files are shown without any protection
- and PHP files (if called directly via filename) get parsed too without any protection (till today we thought they get proxied to Apache too, but this is not the case with these versions of Plesk)
- side note: the PHP directives are really strange in the Nginx config files (not fitting the intention of the configuration Nginx + Apache)
- only requests proxied to Apache are protected (by Apache rules)
For Plesk version 18.0.59 the situation is different (same settings as above):
- first of all: you need to change your website config after the upgrade so that the nginx.conf is rewritten (e.g. change PHP handler or Apache & nginx Settings)
- after this the static files are secured and not accessible anymore without proper credentials
- but: this time Plesk added some wrong Nginx directives leading to the download of PHP files after correct authentification (if directly called)
- and even more worse: the websites are not accessible anymore at all (403 for "normal" requests after successful authentification)
A look at the Nginx config shows the changes:
- the nginx.conf is now completely different
- especially the strange PHP handler configuration was finally gone and replaced by a new setup that fits with the intended configuration
- someone tried to fix the authentification problem, but by doing this a big new bug was introduced:
- PHP files are not handed over to the Apache anymore but downloaded because of a wrong location directive
- actually no request at all are proxied to the Apache anymore leading to the mentioned problems with the 403 (directory listing not available after file could not be found)
Bugfix for the Plesk team:
- the second location block in the following location directive was not a good idea and is the root of all evil here:
- just remove the other location block and put the auth_basic inside the inner block
- 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)
In our opinion this Plesk version should not be rolled-out anymore at this point.
At least there should be a patch within hours, not weeks for such an important security issue.
Questions for the Plesk team:
a) There was no changelog about the "Bugfix" with the broken authentification (a full changelog is essential for sysadmins to know, what needs special attention in the upgrade process). Why is such important information missing?
b) Our developers reported within 5 minutes after the upgrade to 18.0.59 the broken websites, the QC of Plesk failed completely for this version which puts a lot of systems at risk now (download possibility of sensitive PHP files, actually all systems of those password protected websites have to be seen as compromised now, admins should change all affected access credentials in those PHP files). How can such an easy to replicate problem be overseen? Don't you use Plesk servers for your own developers? They should be affected immediately same as our developers?
We checked some of our "older" Plesk servers with Plesk versions 18.0.58.2 and 18.0.57.3.
And one test server with the latest 18.0.59.
For versions 18.0.58.2 and 18.0.57.3 the password protection via the build-in Plesk functionality fails with the following settings:
- activate "Serve static files directly by nginx" (Proxy mode enabled too)
- activate password protection for the whole domain (via hosting dashboard)
- put some files like test.txt and test.php in your public folder
- call the files directly
- password protection is not triggered
The reason can be found in the wrongly generated nginx.conf file for the domain under /var/www/vhosts/system/*:
- the auth_basic directive is missing completely for the requests Nginx is handling alone
- so static files are shown without any protection
- and PHP files (if called directly via filename) get parsed too without any protection (till today we thought they get proxied to Apache too, but this is not the case with these versions of Plesk)
- side note: the PHP directives are really strange in the Nginx config files (not fitting the intention of the configuration Nginx + Apache)
- only requests proxied to Apache are protected (by Apache rules)
For Plesk version 18.0.59 the situation is different (same settings as above):
- first of all: you need to change your website config after the upgrade so that the nginx.conf is rewritten (e.g. change PHP handler or Apache & nginx Settings)
- after this the static files are secured and not accessible anymore without proper credentials
- but: this time Plesk added some wrong Nginx directives leading to the download of PHP files after correct authentification (if directly called)
- and even more worse: the websites are not accessible anymore at all (403 for "normal" requests after successful authentification)
A look at the Nginx config shows the changes:
- the nginx.conf is now completely different
- especially the strange PHP handler configuration was finally gone and replaced by a new setup that fits with the intended configuration
- someone tried to fix the authentification problem, but by doing this a big new bug was introduced:
- PHP files are not handed over to the Apache anymore but downloaded because of a wrong location directive
- actually no request at all are proxied to the Apache anymore leading to the mentioned problems with the 403 (directory listing not available after file could not be found)
Bugfix for the Plesk team:
- the second location block in the following location directive was not a good idea and is the root of all evil here:
Code:
location ~ "^/" {
auth_basic "Please login first...";
auth_basic_user_file "/var/www/vhosts/system/my-test-domain.dev/pd/d..httpdocs";
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;
}
}- 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)
In our opinion this Plesk version should not be rolled-out anymore at this point.
At least there should be a patch within hours, not weeks for such an important security issue.
Questions for the Plesk team:
a) There was no changelog about the "Bugfix" with the broken authentification (a full changelog is essential for sysadmins to know, what needs special attention in the upgrade process). Why is such important information missing?
b) Our developers reported within 5 minutes after the upgrade to 18.0.59 the broken websites, the QC of Plesk failed completely for this version which puts a lot of systems at risk now (download possibility of sensitive PHP files, actually all systems of those password protected websites have to be seen as compromised now, admins should change all affected access credentials in those PHP files). How can such an easy to replicate problem be overseen? Don't you use Plesk servers for your own developers? They should be affected immediately same as our developers?
Similar threads
