Skip to content

Navigation Menu

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

[Security] Tell about erasing credentials when the user is stored in the session #20953

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

Merged
merged 1 commit into from
May 12, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions 5 reference/configuration/security.rst
Original file line number Diff line number Diff line change
Expand Up @@ -53,6 +53,11 @@ erase_credentials
If ``true``, the ``eraseCredentials()`` method of the user object is called
after authentication.

.. deprecated:: 7.3

Since Symfony 7.3, ``eraseCredentials()`` methods are deprecated and are
not called if they have the ``#[\Deprecated]`` attribute.

hide_user_not_found
-------------------

Expand Down
35 changes: 26 additions & 9 deletions 35 security.rst
Original file line number Diff line number Diff line change
Expand Up @@ -193,14 +193,7 @@ from the `MakerBundle`_:
return $this;
}

/**
* @see UserInterface
*/
public function eraseCredentials(): void
{
// If you store any temporary, sensitive data on the user, clear it here
// $this->plainPassword = null;
}
// [...]
}

.. tip::
Expand Down Expand Up @@ -2786,7 +2779,31 @@ object) are "compared" to see if they are "equal". By default, the core
your user will be logged out. This is a security measure to make sure that malicious
users can be de-authenticated if core user data changes.

However, in some cases, this process can cause unexpected authentication problems.
Note that storing the (plain or hashed) password in the session storage can be seen
as a security risk. In order to address this risk, the ``__serialize()`` magic method
can be implemented on the user class to filter out the password before storing the
serialized user object in the session.
Two strategies are supported while serializing:

#. Removing the password entirely. In this case, ``getPassword()`` will return ``null``
after unserialization and Symfony will refresh the user without checking the
password. Use this strategy if you store plaintext passwords (not recommended.)
#. Hashing the password using the ``crc32c`` algorithm. In this case Symfony will
compare the password of the refreshed user after crc32c-hashing it. This is a good
strategy if you use hashed passwords since it allows invalidating concurrent
sessions when a password changes without storing the password hash in the session.

Here is an example of how to implement this, assuming the password is found in a
private property named ``password``::

public function __serialize(): array
{
$data = (array) $this;
$data["\0".self::class."\0password"] = hash('crc32c', $this->password);

return $data;
}

If you're having problems authenticating, it could be that you *are* authenticating
successfully, but you immediately lose authentication after the first redirect.

Expand Down
Morty Proxy This is a proxified and sanitized view of the page, visit original site.