[make:user] user entities implement PasswordAuthenticatedUserInterface

[jrushlow]

Starting in Symfony 5.3 - PR symfony/symfony#40267 introduces the new PasswordAuthenticatedUserInterface & LegacyPasswordAuthenticatedUserInterface aimed at decoupling passwords from the UserInterface.

• Generated User entity implements PasswordAuthenticatedUserInterface if it exists.
• Adds correct type hint to the generated UserRepository::upgradePassword() method.

Authentication related changes are handled in #824

// cc @chalasr

[chalasr]

Looks good to me. Thanks a lot @jrushlow!

[weaverryan]

Why do we need ClassNameDetails here? Can't we just use the normal class strings?

You might be doing this due to the logic in the template to figure out which location the use statement should be. I'd prefer passing in a second flag to know that - e.g. is_using_password_authenticated_interface. That should simplify the template

[jrushlow]

We need the full class name for the use statement and the shortName for the type hint in upgradePassword().

We currently already have a $with_password_upgrade var available in the templates - we could add a $is_using_password_authenticated_interface var as well, but i think that would make things even messier in the template when we need to determine the sort order of the use statements. Ultimately what we really need is a use statement sorter to solve the messy part - but I'm open to ideas.

Also to consider, #824 introduces the concept of a TemplateClassDetails object the returns formatted strings for the particular use case. e.g.

$userDetails = new TemplateClassDetails(User::class, true);    // second arg === $isTyped

$userDetails->getUseStatement();
// use App\Entity\User;

$userDetails->getConstructorArg();
// User $user

$userDetails->getMethodArg();  // similar to the above but spacing is slightly different
// User $user

$userDetails->getVariable();
// $user

$userDetails->getProperty();
// $this->user

// All of the above add appropriate spacing, casing, trailing commas, new lines, etc..

While 824 is not ready yet, ideally if we merge that in with, a lot of stuff in this PR will be refactored to leverage the new helper and cleanup the templates.

[weaverryan]

Ok then!

Ultimately what we really need is a use statement sorter to solve the messy part

👍

[weaverryan]

In both getPassword() and getSalt(), when using 5.3 or 5.4, the messaging should change. For getSalt() it should have some comment about how the method is deprecated - and you can remove it once using 6.0. For getPassword(), the same (unless they are implementing the password interface because they actually need it).

[jrushlow]

Updated the doc blocks for both methods to This method can be removed in Symfony 6.0 - is not needed for apps that do not check user passwords. unless the a user is checking passwords.

For getSalt(), once symfony/symfony-docs#15065 is completed, I figure we can refactor the docBlocks to point to that doc (#854) vs pointing to an interface that may not exist / have a lengthy explanation.

[weaverryan]

Thanks Jesse!