Renamed User to InMemoryUser¶
Contributed by
Robin Chalas
in #40443.
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\Component\Security\Core\User\User). 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: bcrypt Renamed username to identifier¶
Contributed by Wouter De Jong in #40403.
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 now UserInterface::getUserIdentifier() loadUserByUsername() is now loadUserByUserIdentifier(), both in user loaders and user providers UsernameNotFoundException is now UserNotFoundException Decoupled Passwords from Users¶
Contributed by
Robin Chalas
in #40267.
The Symfony\Component\Security\Core\User\UserInterface 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 implements these two interfaces, so you don’t need to change anything in your code. In Symfony 6.0 that will be no longer the case and you’ll need to implement the new interfaces if you need those methods.
Sponsor the Symfony project.
Connectez-vous pour ajouter un commentaire
Autres messages de ce groupe

Contributed by Jérôme Tamarelle in

This week, we kicked off the New in Symfony 7.3 blog series, highlighting all the exciting new features coming in this release. We also unveiled more details about some of the SymfonyOnline June 2025

SymfonyOnline June 2025 is almost here, starting in almost 2 months on:
June 10-11: Workshop days. It is possible to attend 1 two-day training or 2 one-day trainings. June 12-13: Online confe

Symfony's Messenger component makes it easy to build message-driven applications. However, developers using symfony/amqp-messenger have long faced a limitation: it relies on polling (get()), which can

SymfonyLive Berlin 2025 took place just 3 weeks ago!
A huge thank you to everyone who joined us!🔥 The conference brought together the local Symfony community in the heart of Berlin for two da

Contributed by Hubert Lenoir in

SymfonyOnline June 2025 is almost here, starting in almost 2 months on:
June 10-11: Workshop days. It is possible to attend 1 two-day training or 2 one-day trainings. June 12-13: Online confe