[Security] login_check route throws exception on php 5.4.4: Parent session handler is not open #13269

derrabus · 2015-01-05T16:31:58Z

I tried to upgrade my client's Symfony application from 2.5.8 to the lastest 2.6-dev snapshot (12d8261). Unfortunately, the upgrade broke their login process completely, which worked fine with 2.6.1 and below.

I could reproduce the problem by creating a new Symfony Standard application and implementing a login form as described in the cookbook. If I enter correct credentials in the form here, I get the following exception on the login_check route.

[1] Symfony\Component\Debug\Exception\ContextErrorException: Warning: SessionHandler::write(): Parent session handler is not open
    at n/a
        in /home/develop/projects/session-test/app/cache/dev/classes.php line 4606

    at Symfony\Component\Debug\ErrorHandler->handleError('2', 'SessionHandler::write(): Parent session handler is not open', '/home/develop/projects/session-test/app/cache/dev/classes.php', '4606', array('sessionId' => 'vq1u2n2d008k0mbmc2hi0j0v55', 'data' => '_sf2_attributes|a:1:{s:17:"_security_default";s:853:"C:74:"Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken":765:{a:3:{i:0;N;i:1;s:7:"default";i:2;s:722:"a:4:{i:0;O:41:"Symfony\Component\Security\Core\User\User":7:{s:51:"Symfony\Component\Security\Core\User\Userusername";s:4:"demo";s:51:"Symfony\Component\Security\Core\User\Userpassword";s:4:"demo";s:50:"Symfony\Component\Security\Core\User\Userenabled";b:1;s:60:"Symfony\Component\Security\Core\User\UseraccountNonExpired";b:1;s:64:"Symfony\Component\Security\Core\User\UsercredentialsNonExpired";b:1;s:59:"Symfony\Component\Security\Core\User\UseraccountNonLocked";b:1;s:48:"Symfony\Component\Security\Core\User\Userroles";a:1:{i:0;s:9:"ROLE_USER";}}i:1;b:1;i:2;a:1:{i:0;O:41:"Symfony\Component\Security\Core\Role\Role":1:{s:47:"Symfony\Component\Security\Core\Role\Rolerole";s:9:"ROLE_USER";}}i:3;a:0:{}}";}}";}_sf2_flashes|a:0:{}_sf2_meta|a:3:{s:1:"u";i:1420472792;s:1:"c";i:1420472792;s:1:"l";s:1:"0";}'))
        in  line 

    at SessionHandler->write('vq1u2n2d008k0mbmc2hi0j0v55', '_sf2_attributes|a:1:{s:17:"_security_default";s:853:"C:74:"Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken":765:{a:3:{i:0;N;i:1;s:7:"default";i:2;s:722:"a:4:{i:0;O:41:"Symfony\Component\Security\Core\User\User":7:{s:51:"Symfony\Component\Security\Core\User\Userusername";s:4:"demo";s:51:"Symfony\Component\Security\Core\User\Userpassword";s:4:"demo";s:50:"Symfony\Component\Security\Core\User\Userenabled";b:1;s:60:"Symfony\Component\Security\Core\User\UseraccountNonExpired";b:1;s:64:"Symfony\Component\Security\Core\User\UsercredentialsNonExpired";b:1;s:59:"Symfony\Component\Security\Core\User\UseraccountNonLocked";b:1;s:48:"Symfony\Component\Security\Core\User\Userroles";a:1:{i:0;s:9:"ROLE_USER";}}i:1;b:1;i:2;a:1:{i:0;O:41:"Symfony\Component\Security\Core\Role\Role":1:{s:47:"Symfony\Component\Security\Core\Role\Rolerole";s:9:"ROLE_USER";}}i:3;a:0:{}}";}}";}_sf2_flashes|a:0:{}_sf2_meta|a:3:{s:1:"u";i:1420472792;s:1:"c";i:1420472792;s:1:"l";s:1:"0";}')
        in /home/develop/projects/session-test/app/cache/dev/classes.php line 4606

    at Symfony\Component\HttpFoundation\Session\Storage\Proxy\SessionHandlerProxy->write('vq1u2n2d008k0mbmc2hi0j0v55', '_sf2_attributes|a:1:{s:17:"_security_default";s:853:"C:74:"Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken":765:{a:3:{i:0;N;i:1;s:7:"default";i:2;s:722:"a:4:{i:0;O:41:"Symfony\Component\Security\Core\User\User":7:{s:51:"Symfony\Component\Security\Core\User\Userusername";s:4:"demo";s:51:"Symfony\Component\Security\Core\User\Userpassword";s:4:"demo";s:50:"Symfony\Component\Security\Core\User\Userenabled";b:1;s:60:"Symfony\Component\Security\Core\User\UseraccountNonExpired";b:1;s:64:"Symfony\Component\Security\Core\User\UsercredentialsNonExpired";b:1;s:59:"Symfony\Component\Security\Core\User\UseraccountNonLocked";b:1;s:48:"Symfony\Component\Security\Core\User\Userroles";a:1:{i:0;s:9:"ROLE_USER";}}i:1;b:1;i:2;a:1:{i:0;O:41:"Symfony\Component\Security\Core\Role\Role":1:{s:47:"Symfony\Component\Security\Core\Role\Rolerole";s:9:"ROLE_USER";}}i:3;a:0:{}}";}}";}_sf2_flashes|a:0:{}_sf2_meta|a:3:{s:1:"u";i:1420472792;s:1:"c";i:1420472792;s:1:"l";s:1:"0";}')
        in  line 

    at session_write_close()
        in /home/develop/projects/session-test/app/cache/dev/classes.php line 4386

    at Symfony\Component\HttpFoundation\Session\Storage\NativeSessionStorage->save()
        in /home/develop/projects/session-test/app/cache/dev/classes.php line 4214

    at Symfony\Component\HttpFoundation\Session\Session->save()
        in /home/develop/projects/session-test/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/EventListener/SaveSessionListener.php line 55

    at Symfony\Component\HttpKernel\EventListener\SaveSessionListener->onKernelResponse(object(FilterResponseEvent), 'kernel.response', object(ContainerAwareEventDispatcher))
        in  line 

    at call_user_func(array(object(SaveSessionListener), 'onKernelResponse'), object(FilterResponseEvent), 'kernel.response', object(ContainerAwareEventDispatcher))
        in /home/develop/projects/session-test/vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/WrappedListener.php line 59

    at Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke(object(FilterResponseEvent), 'kernel.response', object(ContainerAwareEventDispatcher))
        in  line 

    at call_user_func(object(WrappedListener), object(FilterResponseEvent), 'kernel.response', object(ContainerAwareEventDispatcher))
        in /home/develop/projects/session-test/app/cache/dev/classes.php line 3876

    at Symfony\Component\EventDispatcher\EventDispatcher->doDispatch(array(object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener)), 'kernel.response', object(FilterResponseEvent))
        in /home/develop/projects/session-test/app/cache/dev/classes.php line 3809

    at Symfony\Component\EventDispatcher\EventDispatcher->dispatch('kernel.response', object(FilterResponseEvent))
        in /home/develop/projects/session-test/app/cache/dev/classes.php line 3970

    at Symfony\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('kernel.response', object(FilterResponseEvent))
        in /home/develop/projects/session-test/vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/TraceableEventDispatcher.php line 112

    at Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch('kernel.response', object(FilterResponseEvent))
        in /home/develop/projects/session-test/app/bootstrap.php.cache line 3040

    at Symfony\Component\HttpKernel\HttpKernel->filterResponse(object(RedirectResponse), object(Request), '1')
        in /home/develop/projects/session-test/app/bootstrap.php.cache line 3011

    at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), '1')
        in /home/develop/projects/session-test/app/bootstrap.php.cache line 2982

    at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), '1', true)
        in /home/develop/projects/session-test/app/bootstrap.php.cache line 3131

    at Symfony\Component\HttpKernel\DependencyInjection\ContainerAwareHttpKernel->handle(object(Request), '1', true)
        in /home/develop/projects/session-test/app/bootstrap.php.cache line 2376

    at Symfony\Component\HttpKernel\Kernel->handle(object(Request))
        in /home/develop/projects/session-test/web/app_dev.php line 18

This problem only appears on our old virtual machine running php 5.4.4. On my dev machine running Ubuntu 14.10 with the bundled php 5.5.12, everything works as expected. So, this issue is probably related to that old php version. Maybe, we're facing a similar issue here as in #5868 (just guessing)?

My client is aware, that this php version is fairly old, but the application has several hundred installations and most of them under that old php version, so the migration to a more recent php release will take some time. Untill then, I would need a fix or a workaround.

The text was updated successfully, but these errors were encountered:

linaori · 2015-01-05T20:05:58Z

Well, you are installing a development snapshot, those are known not to be stable. You could try to find the commit causing this by using git bisect

derrabus · 2015-01-05T20:37:19Z

I know and this is not a complaint, just a report. Should I really wait until a final 2.6.2 release before reporting problems? And to be fair: it's a development snapshot of a bugfix release. :-)

linaori · 2015-01-06T07:38:37Z

Reporting problems can always be done, IMO rather sooner than later.

derrabus · 2015-01-06T12:31:38Z

I could trace this problem down to PR #13048. If I revert commit 5dd11e6, the login form works again.

ping @xelaris

derrabus · 2015-01-06T12:51:38Z

Since that commit went into the LTS branch, I've just checked the other branches. I could reproduce this problem with latest 2.3 and 2.5 as well.

xelaris · 2015-01-06T13:02:12Z

I found some related resources. It is probably this PHP bug https://bugs.php.net/bug.php?id=63379 for PHP <= 5.4.11.

There was an issue #5868 describing the same problem, but related to the logout handler, which results in adding a recommendation to SymfonyRequirements.php (sensiolabs/SensioDistributionBundle@2a518e7).

I see three options:

Revert the change and reopen issue Session Saved Twice #13026 (then maybe follow the fallback idea "new strategy" described in [Security] Delete old session on auth strategy migrate #13048)
Make the session_regenerate_id flag parameter related to the PHP version, so that it is only true when running on a PHP version >5.4.11.
Find another workaround

xelaris · 2015-01-06T13:20:40Z

@derrabus Just noticed that you already mentioned issue #5868

fabpot · 2015-01-06T13:26:46Z

As the "fix" went into 2.3, I would vote for reverting the change for now and open a new ticket explaining everything mentioned here.

derrabus · 2015-01-06T13:31:11Z

Thanks for the quick answer, @xelaris. I digged into that issue and came to the same conclusion. I'm in favor for option two, since your patch works well on reasonably new php versions. Adding a new strategy just because of old quirky php versions is overkill, imho. I'd like to keep that complexity out of the framework configuration.

xelaris · 2015-01-06T13:56:19Z

@fabpot I just opened PR #13282 to revert the changes for now and will open a new issue referencing this one and #13026

xelaris · 2015-01-06T14:19:29Z

The new issue is #13283.

@derrabus I'm currently also in favor of passing true to $request->getSession()->migrate() depending on the PHP version. Thanks for reporting the issue.

derrabus · 2015-01-06T14:35:09Z

As an alternative, I've created PR #13286 with the change we've discussed.

fabpot · 2015-01-06T14:59:32Z

@derrabus So, you confirm that this is indeed a PHP bug? In which case we can "just" merge #13286 and closing the other related issues/PRs?

derrabus · 2015-01-06T15:21:58Z

@fabpot Yes. I encounter this problem only in my php 5.4.4 environment and not in my php 5.5.12 environment, so php bug 63379 sounds like a reasonable cause for this issue. To test my application, I have cherry-picked #13286 into the 2.6 branch and it fixes the problem for me.

…. (derrabus) This PR was squashed before being merged into the 2.3 branch (closes #13286). Discussion ---------- [Security] Don't destroy the session on buggy php releases. | Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | BC breaks? | no | Deprecations? | no | Tests pass? | yes | Fixed tickets | #13269, #13283 | License | MIT | Doc PR | none See #13269 for the discussion. This workaround avoids destroying the old session after login on the migrate strategy when running under a php version that we know to be broken. Corresponding php bug: https://bugs.php.net/bug.php?id=63379 Commits ------- 5d0b527 [Security] Don't destroy the session on buggy php releases.

xelaris added a commit to xelaris/symfony that referenced this issue Jan 6, 2015

[Security] reverted PR symfony#13048 due to issue symfony#13269

489d197

xelaris mentioned this issue Jan 6, 2015

[Security] Revert PR #13048 due to issue #13269 #13282

Closed

xelaris mentioned this issue Jan 6, 2015

[Security] Remove old session data on auth strategy migrate #13283

Closed

This was referenced Jan 6, 2015

[Security] Don't destroy the session on buggy php releases. #13285

Closed

[Security] Don't destroy the session on buggy php releases. #13286

Closed

fabpot closed this as completed Jan 7, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Security] login_check route throws exception on php 5.4.4: Parent session handler is not open #13269

[Security] login_check route throws exception on php 5.4.4: Parent session handler is not open #13269

derrabus commented Jan 5, 2015

linaori commented Jan 5, 2015

derrabus commented Jan 5, 2015

linaori commented Jan 6, 2015

derrabus commented Jan 6, 2015

derrabus commented Jan 6, 2015

xelaris commented Jan 6, 2015

xelaris commented Jan 6, 2015

fabpot commented Jan 6, 2015

derrabus commented Jan 6, 2015

xelaris commented Jan 6, 2015

xelaris commented Jan 6, 2015

derrabus commented Jan 6, 2015

fabpot commented Jan 6, 2015

derrabus commented Jan 6, 2015

[Security] login_check route throws exception on php 5.4.4: Parent session handler is not open #13269

[Security] login_check route throws exception on php 5.4.4: Parent session handler is not open #13269

Comments

derrabus commented Jan 5, 2015

linaori commented Jan 5, 2015

derrabus commented Jan 5, 2015

linaori commented Jan 6, 2015

derrabus commented Jan 6, 2015

derrabus commented Jan 6, 2015

xelaris commented Jan 6, 2015

xelaris commented Jan 6, 2015

fabpot commented Jan 6, 2015

derrabus commented Jan 6, 2015

xelaris commented Jan 6, 2015

xelaris commented Jan 6, 2015

derrabus commented Jan 6, 2015

fabpot commented Jan 6, 2015

derrabus commented Jan 6, 2015