Hash de contraseñas en texto plano y PasswordCredentials

Hey @odds

Great question! The short answer is: entities are plain data objects, not services. Doctrine instantiates them via reflection, so you can't inject UserPasswordHasherInterface into them. That $this->passwordHasher would never exist.
But your instinct to centralize the hashing is totally valid! The most common approach is a Doctrine entity listener. The idea is:

Every code path (fixtures, registration, change password) just calls $user->setPlainPassword('the-plain-password') instead of hashing manually.
A listener on prePersist and preUpdate checks if plainPassword is set, hashes it, and stores the result in password.

One gotcha: since plainPassword is not a mapped field, Doctrine won't detect a change on update. A common trick is to also null out $this->password inside setPlainPassword() to force Doctrine's change tracking to pick it up.
Or, you can dispatch a custom event in every place you update the password, which is not as helpful as Doctrine events, but there would be less magic going on.

We keep things simple in this tutorial to avoid introducing too many concepts at once. Cheers!

Hey @kakhaber

What Symfony version are you using? Does your user entity implement the Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface interface?

Cheers!

Hey Arman,

I'm not sure I completely understand you here. If you ask why we show the login feature first and after the registration feature instead of showing it in reverse order - well, that's not very important actually, but the login feature is easier because we use some data from the fixtures. Registration is a bit more complex, and it will require knowing how the login feature works eventually, so once again it's a good idea to meet with the login feature first. Last but not least, actually, the registration feature is not required for some websites, I mean, having a user registration on your website isn't a rule but is mostly an optional feature. There might be some websites where users just access the content without being able to authorize themselves because it's not necessary.

But your question is also valid, and showing it in the reverse order is kinda OK too. But as I said, it's not that important, and it was already recorded this way by the course author. I hope this answers your question :)

Cheers!

Yeah you got my question right, and now I understand you perfectly.
Thanks very much.

Hey @Francois

My apologies for the bad feeling, that's not the experience we want our users to have. After hashing the user password you can set it on the object, basically as you please, usually via a setter method.
About the hasher using the email as part of the password. It does not do that, the only field it gets from the user object is the salt in case your app supports it, but it is not recommended when using modern hashing algorithms

I hope I managed to clarify things. Cheers!

I foun the prob.

My methode getPAssword() in USer entity return null

Good night :)

Hey Amine,

I'm happy to hear you were able to find the problem yourself, well done! And thanks for sharing your solution with others ;)

Cheers!

Hey @MattWelander!

Hmm, that's interesting! The point of the "auto" is that you no longer need to really care what algorithm is being used, because it'll choose whatever the latest and greatest is. That being said, I would definitely expect that security:encode-password and using the UserPasswordHasherInterface service in PHP would use the same algorithm. The algorithm is chosen, iirc, entirely based on the User class (well, the User class is used to look up your hasher config - so basically, it's chosen based on your hasher config, which does not change between php and that console command). So I also would expect to see $argon style hashed passwords in both cases. When I just checked Symfonycasts, indeed, that IS what I see: both ways give me $argon2 style hashed password.

So... that's a mystery why doing that in PHP would result in a non-argon hasher being used - I can't explain that...

Cheers!

Nevermind - that question is answered a few lessons down the line =) https://symfonycasts.com/screencast/symfony-security/entry-point

Solved - need to add -->"
symfony console doctrine:query:sql 'SELECT * FROM "user"'<br />

Hey Maxim,

Yeah, user might be a reserved keyword, usually we wrap table names with tick. Thank you for sharing your solution!

Cheers!

Hey Mepcuk!

Yes! But we can even do a bit less work:

A) You can skip setting the plain password and just do $this->passwordHasher->hashPassword($user, 'tada')

B) You only need one flush(). Remove the first one and just flush/save once after you set the real password. Also, you can then remove the $user->setPassword('tada'). I'm guessing you had that just so that your database didn't throw an error during the first flush ;).

Cheers!