Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Argument 1 passed to AbstractToken::__unserialize() must be of type array, string given #36813

Closed
rfaivre opened this issue May 13, 2020 · 3 comments

Comments

@rfaivre
Copy link
Contributor

rfaivre commented May 13, 2020

Symfony version(s) affected: 4.4.8
php version 7.2

Description
After upgrading from Symfony 3.4 to Symfony 4.4.8, I have a problem during the authentication process.
When the token is retrieved from the session and try to be unserialized, I have this error:

Argument 1 passed to Symfony\\Component\\Security\\Core\\Authentication\\Token\\AbstractToken::__unserialize() must be of the type array, string given, called in /data/vendor/symfony/security-core/Authentication/Token/UsernamePasswordToken.php on line 103 at /data/vendor/symfony/security-core/Authentication/Token/AbstractToken.php:200)"}

In this function of the UsernamePasswordToken.php file:

    /**
     * {@inheritdoc}
     */
    public function __unserialize(array $data): void
    {
        [$this->credentials, $this->providerKey, $parentData] = $data;
        parent::__unserialize($parentData);
    }

$parentData is still serialized. Or, it should be an array. The declaration of __unserialize takes in an array.

Of course, after if I cleared my cookies, everything works well, but it's not the best solution.

How to reproduce
Do an authentication with Symfony 3.4.
Upgrade to Symfony 4.4.8 with the same PHP version (7.2)
Try authentication.

Does Anyone reproduce also this issue?
Some help is appreciated :)

@wouterj
Copy link
Member

wouterj commented May 13, 2020

Are you trying to use a token generated by a 3.4 application in the 4.4 application? (the $parentData variable was a string in 3.4) I believe this is an unsupported use-case (just like cache might break between minor versions).

@rfaivre
Copy link
Contributor Author

rfaivre commented May 14, 2020

Yes, the token was generated in 3.4 application and used in 4.4 app

Maybe another check before passing to __unserialize to ensure the $parentData is an array and not break the compatibility?

$parentData = \is_array($parentData) ? $parentData : unserialize($parentData)

@nicolas-grekas
Copy link
Member

Did you try this on your app @rfaivre? Does it work?
If confirmed, you could maybe send a PR?

nicolas-grekas added a commit that referenced this issue May 18, 2020
…rors (rfaivre)

This PR was squashed before being merged into the 4.4 branch.

Discussion
----------

[Security] Unserialize $parentData, if needed, to avoid errors

Check that the $parentData is an array. If it's a string, the variable is unserialized.
Useful to not break the compatibility with the older versions.
Bug reproduced when upgrading from 3.4 to 4.4

| Q             | A
| ------------- | ---
| Branch?       | 4.4
| Bug fix?      | yes
| New feature?  | no
| Deprecations? | no
| Tickets       | Fix #36813
| License       | MIT
| Doc PR        | symfony/symfony-docs#... <!-- required for new features -->

Commits
-------

b447433 [Security] Unserialize $parentData, if needed, to avoid errors
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants