I'm using PHP7 to start sessions using my favorite control method: URL paths. This used to work [the way I'm doing it] but doesn't work in PHP7. Let's start with a completely normal hello world example.
<?php
session_start();
if(TRUE){
$_SESSION['test'] = 'Hello World!';
}
print_r($_SESSION);
echo "<P>".session_id();
Run it first with TRUE and this baby works perfectly. Set it to FALSE and you get what you expect. Run it over and over and you get the same, expected result. I can even visit the session file and see that the variables were saved.
Now, I'm a fan of controlling my code using domain paths. E.G., example.com/action1/action2. Action1 is identified in my .htaccess file as a PHP type file and my doc_root has a symbolic link, action1 -> index.php. Please note, this works fine in every way but one... the moment you add those paths to the URI, the session stops reading the variables.
Can you help me understand why? Yes, the obvious solution to the question, "it hurts when I do this, what should I do?" is "don't do that." But like I said, I'm a fan. Frankly, this should work. The one and only cookie is correct. session_id() reports that I am looking at the same session ID and file. The very same session ID that is filled with data. Remove the /action1/action2 component and the $_SESSION variables show up again, just as we'd expect.
Does anyone know why this happens? What is it about adding the path that disables the session? Why would PHP even care so long as it has the expected session id? I even tried to file_get_contents() the session file so I could session_decode() the contents. Without the action path, I can read and process the file. With the action path (drum roll please...) I can't even read the file. It's as if some kind of ownership change has occured, but I have the file and directory permissions wide open. Any ideas?
.htaccess:
RewriteEngine On
RewriteBase /
AddHandler application/x-httpd-php70 .php
<Files action1>
SetHandler application/x-httpd-php
</Files>
EDIT: If you want to test this yourself. Save the first file to test.php, then update your .htaccess file as shown. Finally, ln -s test.php action1. Run domain.com/test.php to prove to yourself the sessions are working. Then run domain.com/action1 and watch the variables disappear.
As it turns out, @hakre was on the right path, but the change didn't solve the problem. The problem is that Plesk directly assigns *.php files to be processed through php_fpm. In the Virtual Host Apache configuration file we have...
<Files ~ (\.php$)>
SetHandler proxy:unix:///var/www/vhosts/system/wwphelps.com/php-fpm.sock|fcgi://127.0.0.1:9000
</Files>
This is how Plesk is specifically attaching one version of PHP over another by domain name. And anything that doesn't fall into this rule is interpreted by Apache's global rules, which for me are looking at a different install of PHP. (Why Plesk doesn't have a global override to point at their own PHP installs is a bit of a wonder, but I suspect this is a bug they've never encountered before.) So, logically, we'd need only add for each file we want to process without the .php suffix...
<Files action1>
SetHandler proxy:unix:///var/www/vhosts/system/wwphelps.com/php-fpm.sock|fcgi://127.0.0.1:9000
</Files>
It is true that you need to do this, but for me it didn't work as advertised. My web page simply said "Access Denied" and my error files pointed me to FPM's security.limit_extensions paramter. In other words, despite specifically identifying a file I wanted to use without a suffix, FPM rejected it anyway. Here's where I got lazy. I reset the variable to nothing. In Plesk that's done by creating or modifying a php.ini file inside the domain's conf directory and adding (including the header if it's not already there)...
[php-fpm-pool-settings]
security.limit_extensions =
Restart Apache and Bob's your uncle.
According to a really rapid Google search, the ability to directly modify FPM parameters from inside Plesk is still up for debate.
Now, this comes with a price. From the perspective of the FPM socket, suddenly any file in you're web root "could" be executed as a PHP file, including images customers upload and you blindly put in your [ROOT]/images directory. You're partially saved by the fact that unless you've told Apache otherwise, just any old file won't be interpreted as a PHP file. However, you'd be better protected if all files you upload through your site are (a) thoroughly vetted to be sure they are what they claim to be and (b) are either saved outside the web root or in a DB so that nobody can "execute" them by referring to them directly.
Finally, there ought to be a way to override in a config file those files that I want to intentionally violate security.limit_extensions. Unfortunately, FPM and Apache don't appear to talk to each other, otherwise the use of the block would completely override security.limit_extensions. For all I know there's a way to do it. I'd be curious to know, but I have a working solution, so I'm back to work.
You are using two different PHP versions:
The application/x-httpd-php70 handler per default for all .php files.
And on the other hand, the application/x-httpd-php handler for file starting with action1.
When you add that path, apache uses a different PHP configuration which might block or use a different session store. I can't say in specific as I have never created such a setup, but it's likely you just have forgotten to use the same action handler for the files.
That is action handler configuration in Apache. See the docs https://httpd.apache.org/docs/2.4/handler.html so that you can better understand what is going on (and perhaps as well where that second PHP is from, you should be able to find that in the Apache configurtion).