Using this PHP 7 VM and
PHP 7.0.0-dev (cli) (built: May 25 2015 16:32:16), sessions are not properly managed within Joomla. When attempting to install the application, the installer never moves beyond the first page and internal debugging leads to
JSession::isNew() returning true when it should not be (the session should be started with the initial request to the installer and the first POST should continue that session). The installer specifically reaches this redirect when checking the token on the first POST.
After installing the application on the same VM using PHP 5.6, I was able to confirm that the server configuration is correct. Switching back to PHP 7 and attempting to login yields similar results; this points to an API issue with our code.
Sessions should be correctly managed by the Joomla API.
The Joomla API does not correctly track sessions.
PHP 7 built from its master branch running from this VM
Testing with #5088 merged things still don't work correctly. However, changing the internal handler from the
JSessionHandlerJoomla object to
JSessionHandlerNative does result in sessions working correctly for the whole system. So our issue is narrowed down specifically to the startup sequence our code.
Long and short, the issue relates to the use of JInputCookie. It is reproducible at the Framework level using the master branch of https://github.com/mbabker/session-test as well which uses the Framework version of JInputCookie. Running a test case with a proposed rewrite of the Session package using my repo's v2 branch (which isn't using the problem class) has the session at least booting up but the internal counter is incrementing twice for each hit instead of the intended once.
Something went wrong when use linked $_COOKIE in
// Set the data source. $this->data = $_COOKIE;
// Set the data source. $this->data = &$_COOKIE;
It looks like that's a distinct possibility then which would affect all of the JInput classes (that change isn't really well documented in the upgrading guide unfortunately).
So, I guess my first logical question would be what are the implications of changing JInput to not use a
& reference to the superglobals?
do not use
& most simple/obvious solution
but if it really PHP 7 bug, then maybe we have a chance to get it fixed,
I just not found how to confirm it, how to write some sample code to reproduce the bug
Let me spend a little time building a small app in pure PHP following our construct logic and we'll see what happens.
That file is a minimalistic script using our session boot sequence, I can duplicate the issue with accessing
$_COOKIE by reference with it and removing the reference character gets things working fine.
I guess a more accurate script would have also accessed
$_REQUEST by reference as the base
JInput does by default, but this is close enough to cover our needs.
The upstream bug has been fixed and I've verified things are working as expected with the
3.5-dev branch using the PHP 7 VM linked above on the current PHP master branch.
|Closed_Date||0000-00-00 00:00:00||⇒||2015-06-28 15:27:07|