Symfony 3.4.22 session not compatible with 3.4.21

[jmalinens]

Symfony version(s) affected: 3.4.22 PHP7.1

Description
Symfony 3.4.22 session is not compatible with 3.4.21.

Error:

Symfony\Component\Debug\Exception\ContextErrorException:
Warning: unserialize() expects parameter 1 to be string, array given

  at vendor/symfony/symfony/src/Symfony/Component/Security/Core/Authentication/Token/AbstractToken.php:155

Probably related to:
#30006

How to reproduce
Create session in Symfony 3.4.22 app and try to re-use this session in 3.4.21 application.

Additional context
Full stack trace:

Symfony\Component\Debug\Exception\ContextErrorException:
Warning: unserialize() expects parameter 1 to be string, array given

  at vendor/symfony/symfony/src/Symfony/Component/Security/Core/Authentication/Token/AbstractToken.php:155
  at Symfony\Component\Security\Core\Authentication\Token\AbstractToken->unserialize(array(object(User), true, array(object(Role)), array()))
     (vendor/symfony/symfony/src/Symfony/Component/Security/Core/Authentication/Token/UsernamePasswordToken.php:103)
  at Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken->unserialize('a:3:{i:0;s:40:"XXXX";i:1;s:12:"secured_area";i:2;a:4:{i:0;C:32:"XXXXXX\\Entity\\User":88:{[2912100,"XXXXXX",111111,"XXXXX","XXXXX","Europe\\/Dublin","XXXXX","XXXXX","open"]}i:1;b:1;i:2;a:1:{i:0;O:41:"Symfony\\Component\\Security\\Core\\Role\\Role":1:{s:47:"' . "\0" . 'Symfony\\Component\\Security\\Core\\Role\\Role' . "\0" . 'role";s:9:"ROLE_USER";}}i:3;a:0:{}}}')
  at unserialize('C:74:"Symfony\\Component\\Security\\Core\\Authentication\\Token\\UsernamePasswordToken":385:{a:3:{i:0;s:40:"XXXXX";i:1;s:12:"secured_area";i:2;a:4:{i:0;C:32:"XXXXX\\Entity\\User":88:{[2912100,"XXXXX",1111,"iXXXXX","XXXXXXX","Europe\\/Dublin","XXXXX","XXXXX","open"]}i:1;b:1;i:2;a:1:{i:0;O:41:"Symfony\\Component\\Security\\Core\\Role\\Role":1:{s:47:"' . "\0" . 'Symfony\\Component\\Security\\Core\\Role\\Role' . "\0" . 'role";s:9:"ROLE_USER";}}i:3;a:0:{}}}}')
     (vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/ContextListener.php:246)
  at Symfony\Component\Security\Http\Firewall\ContextListener->safelyUnserialize('C:74:"Symfony\\Component\\Security\\Core\\Authentication\\Token\\UsernamePasswordToken":385:{a:3:{i:0;s:40:"XXXXXX";i:1;s:12:"secured_area";i:2;a:4:{i:0;C:32:"XXXXXX\\Entity\\User":88:{[2912100,"XXXXX",11111,"XXXXXX","XXXXX","Europe\\/Dublin","XXXXX","XXXXX","XXXXX"]}i:1;b:1;i:2;a:1:{i:0;O:41:"Symfony\\Component\\Security\\Core\\Role\\Role":1:{s:47:"' . "\0" . 'Symfony\\Component\\Security\\Core\\Role\\Role' . "\0" . 'role";s:9:"ROLE_USER";}}i:3;a:0:{}}}}')
     (vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/ContextListener.php:95)
  at Symfony\Component\Security\Http\Firewall\ContextListener->handle(object(GetResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Bundle/SecurityBundle/Debug/WrappedListener.php:46)
  at Symfony\Bundle\SecurityBundle\Debug\WrappedListener->handle(object(GetResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Bundle/SecurityBundle/Debug/TraceableFirewallListener.php:35)
  at Symfony\Bundle\SecurityBundle\Debug\TraceableFirewallListener->handleRequest(object(GetResponseEvent), object(Generator))
     (vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall.php:84)
  at Symfony\Component\Security\Http\Firewall->onKernelRequest(object(GetResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Bundle/SecurityBundle/EventListener/FirewallListener.php:48)
  at Symfony\Bundle\SecurityBundle\EventListener\FirewallListener->onKernelRequest(object(GetResponseEvent), 'kernel.request', object(TraceableEventDispatcher))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/WrappedListener.php:111)
  at Symfony\Component\EventDispatcher\Debug\WrappedListener->__invoke(object(GetResponseEvent), 'kernel.request', object(ContainerAwareEventDispatcher))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:212)
  at Symfony\Component\EventDispatcher\EventDispatcher->doDispatch(array(object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener), object(WrappedListener)), 'kernel.request', object(GetResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/EventDispatcher.php:44)
  at Symfony\Component\EventDispatcher\EventDispatcher->dispatch('kernel.request', object(GetResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Component/EventDispatcher/Debug/TraceableEventDispatcher.php:143)
  at Symfony\Component\EventDispatcher\Debug\TraceableEventDispatcher->dispatch('kernel.request', object(GetResponseEvent))
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:127)
  at Symfony\Component\HttpKernel\HttpKernel->handleRaw(object(Request), 1)
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/HttpKernel.php:68)
  at Symfony\Component\HttpKernel\HttpKernel->handle(object(Request), 1, true)
     (vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php:200)
  at Symfony\Component\HttpKernel\Kernel->handle(object(Request), 1, true)
     (app/AppKernel.php:51)
  at AppKernel->handle(object(Request))
     (web/index.php:18)

[antonch1989]

The problem is in parent::unserialize($parentStr) call in the classes extending AbstractToken. There is an attempt to call parent method with an array argument.

[nicolas-grekas]

Hello, yes, that's correct. Yet there is no way around - relying on the Serializable interface produces other range of very nasty bugs. You might consider creating a session with a latest version and loading it with an older one unsupported.

[ibrambe]

In my humble opinion, this change isn't something that belongs in a patch version...

[nicolas-grekas]

See #29951 for some background on this. I get it's not ideal, but the status quo was even worse, with broken payloads.

[UFTimmy]

@nicolas-grekas The problem was up until this change, sharing sessions among Symfony versions worked great. I have a suite of 15 Symfony applications ranging from 2.7 to 3.4 and they all shared sessions for security happily. We have years of work built around that assumption, because up until now they had been working fine.

But then this patch version happened that broke backwards compatibility. I was under the impression that Symfony patch versions would not do that.

I guess it's already been decided that this is ok, but it's disappointing.

Any suggestions for how to provide the same single sign on functionality among a series of apps? Up until now sharing a firewall configuration was enough.

[derrabus]

So a Symfony 2.7 and a Symfony 3.4 application are sharing the same session? Assuming that serialized objects remain compatible if you switch the major version of a library sounds pretty unsafe to me. I'm actually surprised that it has worked so far.

I mean, you can fork Symfony 2.7 and apply the patch there. That might get you a compatible version, but there's no guarantee that this won't break again.

[UFTimmy]

I don't think I assumed anything would work the same across major versions. Nor even minor versions. We tend to test out major and minor versions very heavily before going forward with them.

However, I did not expect a core thing to change across a patch version.

[jmalinens]

we have the same issue.
We use symfony for huge multi-purpose website which consists of 10+ products with version range from 2.8 to 3.4. We are not ready to update all these websites at once. it will be nightmare to manage this