New in Symfony 5.3: Improvements for Security Users

May 3, 2021 • Published by Javier Eguiluz

Symfony 5.3 is backed by:

JoliCode is a team of passionate developers and open-source lovers, with a strong expertise in PHP & Symfony technologies. They can help you build your projects using state-of-the-art practices.

Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.

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 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.

Published in #Living on the edge

Help the Symfony project!

As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.

Comments

Lyubomir Grozdanov Certified said on May 3, 2021 at 10:22

Very nice! Thank you 💥💥💥

Nikolai Plath said on May 3, 2021 at 13:56

Excellent!

Robin Chalas said on May 3, 2021 at 15:07

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.

That's not really true: UserInterface does not extend these two interfaces. But UserInterface still contains the getPassword() and getSalt() 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).

Javier Eguiluz Certified said on May 3, 2021 at 15:37

@Robin thanks for reviewing the blog post! I've made the changes that you suggested.

Rareș Șerban said on May 4, 2021 at 08:23

Why have the names like getUserIdentifier instead of getIdentifier? This one doesn't seem that bad, but loadUserByUserIdentifier instead of loadUserByIdentifier is a mouthful. Don't see the reason to include user in the name each time. If you don't want to be confused with some other identifier, maybe security can be used, eg: loadUserBySecurityIdentifier

Wouter de Jong said on May 6, 2021 at 17:52

@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() and getId() 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!

Jacek Krysztofik said on Jun 9, 2021 at 22:21

Why does UserInterface NOT declare the getUserIdentifier() method?

Nebojša Kamber said on Jun 10, 2021 at 13:25

@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

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.

New in Symfony 5.3: Improvements for Security Users

Renamed User to InMemoryUser

Renamed username to identifier

Decoupled Passwords from Users

Comments

Renamed `User` to `InMemoryUser`

Renamed `username` to `identifier`