Renamed User to InMemoryUser
In Symfony applications, the memory user provider allows to create users (and define their credentials) in a configuration file which is loaded in memory, without using databases or any other persisting service.
Although this user provider is only for prototypes or very small/special
applications, it's based on a class called User (the entire namespace is
Symfony). This confuses some newcomers,
who think this is the main User class in Symfony security.
That's why in Symfony 5.3 we've renamed User to InMemoryUser and
UserChecker to InMemoryUserChecker to better convey their purpose
(in 5.3 the old names still work but they are deprecated and in Symfony 6.0
they will be removed):
1 2 3 4 5
# config/packages/security.yaml
security:
password_hashers:
- Symfony\Component\Security\Core\User\User: bcrypt
+ Symfony\Component\Security\Core\User\InMemoryUser: bcryptRenamed username to identifier
Another source of confusion related to users is the concept of "username" which is used in the Symfony security. In many applications this username is not a traditional username, but an email or even some API token.
That's why in Symfony 5.3 we've decided to avoid this confusion and we've renamed "username" to "user identifier". This might require some changes in your application code (in 5.3 the old names still work but they are deprecated and in Symfony 6.0 they will be removed):
UserInterface::getUsername()is nowUserInterface::getUserIdentifier()loadUserByUsername()is nowloadUserByUserIdentifier(), both in user loaders and user providersUsernameNotFoundExceptionis nowUserNotFoundException
Decoupled Passwords from Users
The Symfony is implemented by all
the security users in Symfony applications. Sadly, this interface is a product
of its time and it contains some methods that are no longer used in modern applications.
The first unneeded method is getSalt(), which is no longer necessary when
using modern password hashing algorithms (bcrypt, Argon2, etc.) This method has
been moved to a new LegacyPasswordAuthenticatedUserInterface.
The other method is getPassword() which is no longer needed in many
password-less features, such as login links. This method has been moved to a
new PasswordAuthenticatedUserInterface.
In Symfony 5.3, UserInterface still contains the getPassword() and
getSalt() methods (they will be removed in Symfony 6.0). However, when
upgrading to Symfony 5.3, you need to implement the new interfaces if you use
those methods.
Very nice! Thank you 💥💥💥
Excellent!
That's not really true: UserInterface does not extend these two interfaces. But UserInterface still contains the
getPassword()andgetSalt()methods until 6.0, for BC. When upgrading to 5.3, you do need to change your code if your users are authenticated using a password (implement the new interface(s) that you need).@Robin thanks for reviewing the blog post! I've made the changes that you suggested.
Why have the names like
getUserIdentifierinstead ofgetIdentifier? This one doesn't seem that bad, butloadUserByUserIdentifierinstead ofloadUserByIdentifieris a mouthful. Don't see the reason to includeuserin the name each time. If you don't want to be confused with some other identifier, maybesecuritycan be used, eg:loadUserBySecurityIdentifier@Rareș Șerban you got it completely correct: "identifier" is a very generic term. We expect most of the applications to use a Doctrine Entity (or some other ORM) as Security user, and having both
getIdentifier()andgetId()in one class would be very confusing.I think "user identifier" is better than "security identifier": it's the most specific ("security" is still generic) and it's shorter than "security" (so less a mouthful ;-) ). If you disagree, feel free to open an issue at https://github.com/symfony/symfony/issues/new/ to discuss it in more detail!
Why does UserInterface NOT declare the getUserIdentifier() method?
@Jacek Krysztofik Declaring it in an interface would be a BC break, since every class implementing it would have to have that method. They just hinted that method in annotations, so we can prepare for Symfony 6. The actual declaration will be in Symfony 6