Does this really fit in the architecture of the new system where this User class is considered for deprecation ?

given the current situation, i figured the mapping was missing from an implementation pov, hence im 👍🏻

however i do think we should rename it to InMemoryUser eventually

LdapUser provides the same feature set, let alone user entites in the wild providing the full app feature set ... then this seems reasonable :)

I personally only see a use-case for the in-memory provider in simple demo applications. Do we really want to advocate using it in real applications? If the answer is no, then I'm in favor of not adding more lines that we need to maintain.

(btw, I would not say that the User is up for deprecation, but hopefully the credential related methods are. Any security system needs to have some sort of user/principal)

https://symfony.com/doc/current/security/user_provider.html#memory-user-provider

It’s not recommended to use this provider in real applications because of its limitations and how difficult it is to manage users.

we fix some limitation here. Managing YAML is debatable 😁

It may be useful in application prototypes and for limited applications that don’t store users in databases.

So it is useful for limited (non-prototype) apps actually?

IMHO it's just a persistence layer, and if in-memory fits ... it fits :)

It's not a "real" persistence layer, as it requires to use Symfony's User. Btw, it's very easy to implement your own in-memory user provider that uses a custom User class with all properties it needs:

class MyInMemoryUserProvider implements UserProvider
{
    private const USERS = [
        'wouter' => [...],
        // ...
    ];

    public function loadUserByUsername(string $username)
    {
        if (!$user = self::USERS[$username] ?? false) {
            throw new UsernameNotFoundException();
        }

        return new AppUser($user['username'], $user['password'], ...);
    }

    public function refreshUser(UserInterface $user)
    {
        return $this->loadUserByUsername($user->getUsername());
    }

    public function supportsClass(string $class)
    {
        return is_a($class, AppUser::class);
    }
}

So I'm honestly leaning more and more towards not adding more properties to the User class.

I personally only see a use-case for the in-memory provider in simple demo applications.

For context,
I've used in-memory provider on apps that only have one or two API users. Think of an internal microservice with a HTTP API.

Hello, i am not aware of the deprecation of this class, where can i find more?

Also, as the prop already exists, i think it is more « finishing » the implementation than adding a new one
I do use very much this feature of in memory provider for apps where i do need only one or very few users (api, unitary admin) and having this extrafields could help avoid adding user related data in a « hacky » way

We don't need to deprecate this class and the corresponding provider, only renaming it (already possible) and make it follow the rework of the UserInterface when it's time to.
This makes configurable a property that already exists on something that has no on-going rework and has been proven useful, nothing fancy here.
There is no reason to "feature freeze" this code area, I think we should relax and just let the work happen as it comes.

Rebase needed. Don't hesitate to tell us if you need help to finish this PR @noniagriconomie

@chalasr rebase done and a test added
review appreciated :)

I agree with @wouterj and I don't think we want to add this feature. I understand the use case and I have the same on some small applications. But as already mentioned, there are simple ways to achieve what you want without support in the framework. Even if adding it in core in not a lot of code, I think that this sends the wrong signal.

@noniagriconomie would you then send the proposed code snippet by Wouter as a docs PR to help others achieve this more easily? Thanks

For reference: the extraFields property in User was added specially for LDAP: #31532 (back then, the specialized LdapUser didn't exists yet). It may even make sense to deprecate that functionality in the main User imho.

hey, ok understood even if I really thought this was a nice addition
lets close for now, I will see if a doc snippet could be usefull