Adding & Checking the User's Password

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $12.00

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

Until now, we've allowed users to login without any password. As much fun as it would be to deploy this to production... I think we should probably fix that. If you look at your User class, our users actually don't have a password field at all:

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 17
private $id;
... lines 19 - 22
private $email;
... lines 24 - 27
private $roles = [];
... lines 29 - 32
private $firstName;
... lines 34 - 116
}

When you originally use the make:user command, you can tell it to create this field for you. We told it to not do this... just to keep things simpler as we were learning. So, we'll do it now.

Adding the password Field to User

Find your terminal and run:

php bin/console make:entity

Update the User class to add a new field called password. Make it a string with length 255. It doesn't need to be quite that long, but that's fine. Can it be null? Say no: in our system, each user will always have a password.

And... done! It updated the User.php file, but it did not generate the normal getPassword() method because we already had that method before. We'll check that out in a minute.

Before that, run:

php bin/console make:migration

Move over and check out the Migrations directory. Open the new file and... yes! It looks perfect: ALTER TABLE user ADD password:

... lines 1 - 10
final class Version20180831181732 extends AbstractMigration
{
public function up(Schema $schema) : void
{
... lines 15 - 17
$this->addSql('ALTER TABLE user ADD password VARCHAR(255) NOT NULL');
}
public function down(Schema $schema) : void
{
... lines 23 - 25
$this->addSql('ALTER TABLE user DROP password');
}
}

Close that, go back to your terminal, and migrate:

php bin/console doctrine:migrations:migrate

Awesome!

Updating the User Class

Go open the User class. Yep - we now have a password field:

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 34
/**
* @ORM\Column(type="string", length=255)
*/
private $password;
... lines 39 - 128
}

And all the way at the bottom, a setPassword() method:

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 122
public function setPassword(string $password): self
{
$this->password = $password;
return $this;
}
}

Scroll up to find getPassword():

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 85
/**
* @see UserInterface
*/
public function getPassword()
{
// not needed for apps that do not check user passwords
}
... lines 93 - 128
}

This already existed from back when our user had no password. Now that it does, return $this->password:

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 85
/**
* @see UserInterface
*/
public function getPassword()
{
return $this->password;
}
... lines 93 - 128
}

Oh, and just to be clear, this password will not be a plain-text password. No, no, no! The string that we store in the database will always be properly salted & encoded. In fact, look at the method below this: getSalt():

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 93
/**
* @see UserInterface
*/
public function getSalt()
{
// not needed for apps that do not check user passwords
}
... lines 101 - 128
}

In reality, there are two things you need to store in the database: the encoded password and the random salt value that was used to encode the password.

But, great news! Most modern encoders - including the one we will use - store the salt value as part of the encoded password string. In other words, we only need this one field. And, the getSalt() method can stay blank. I'll update the comment to explain why:

... lines 1 - 10
class User implements UserInterface
{
... lines 13 - 93
/**
* @see UserInterface
*/
public function getSalt()
{
// not needed when using bcrypt or argon
}
... lines 101 - 128
}

I love doing no work!

Configuring the Encoder

Symfony will take care of all of this password encoding stuff for us. Nice! We just need to tell it which encoder algorithm to use. Go back to security.yaml. Add one new key: encoders. Below that, put the class name for your User class: App\Entity\User. And below that, set algorithm to bcrypt:

security:
encoders:
App\Entity\User:
algorithm: bcrypt
... lines 5 - 44

Tip

In Symfony 4.3, you should use auto as your algorithm. This will use the best possible algorithm available on your system.

There are at least two good algorithm options here: bcrypt and argon2i. The argon2i encoder is actually a bit more secure. But, it's only available on PHP 7.2 or by installing an extension called Sodium.

If you and your production server have this available, awesome! Use it. If not, use bcrypt. Just know that once you start encoding passwords, changing algorithms in the future is a pain.

Oh, and for both encoders, there is one other option you can configure: cost. A higher cost makes passwords harder to crack... but will take more CPU. If security is really important for your app, check out this setting.

Anyways, thanks to this config, Symfony can now encrypt plaintext passwords and check whether a submitted password is valid.

Encoding Passwords

Open the UserFixture class because first, we need to populate the new password field in the database for our dummy users.

To encode a password - surprise! - Symfony has a service! Find your terminal and run our favorite:

php bin/console debug:autowiring

Search for "password". There it is! UserPasswordEncoderInterface. This service can encode and check passwords. Back in UserFixture, add a constructor with one argument: UserPasswordEncoderInterface. I'll re-type the "e" and hit tab to autocomplete and get the use statement I need on top. Call it $passwordEncoder:

... lines 1 - 6
use Symfony\Component\Security\Core\Encoder\UserPasswordEncoderInterface;
class UserFixture extends BaseFixture
{
... lines 11 - 12
public function __construct(UserPasswordEncoderInterface $passwordEncoder)
{
... line 15
}
... lines 17 - 34
}

Press Alt+Enter and select initialize fields to create that property and set it:

... lines 1 - 8
class UserFixture extends BaseFixture
{
private $passwordEncoder;
public function __construct(UserPasswordEncoderInterface $passwordEncoder)
{
$this->passwordEncoder = $passwordEncoder;
}
... lines 17 - 34
}

Now... the fun part: $user->setPassword(). But, instead of setting the plain password here - which would be super uncool... - say $this->passwordEncoder->encodePassword():

... lines 1 - 8
class UserFixture extends BaseFixture
{
... lines 11 - 17
protected function loadData(ObjectManager $manager)
{
$this->createMany(10, 'main_users', function($i) {
... lines 21 - 24
$user->setPassword($this->passwordEncoder->encodePassword(
... lines 26 - 27
));
... lines 29 - 30
});
... lines 32 - 33
}
}

This needs two arguments: the $user object and the plain-text password we want to use. To make life easier for my brain, we'll use the same for everyone: engage:

... lines 1 - 8
class UserFixture extends BaseFixture
{
... lines 11 - 17
protected function loadData(ObjectManager $manager)
{
$this->createMany(10, 'main_users', function($i) {
... lines 21 - 24
$user->setPassword($this->passwordEncoder->encodePassword(
$user,
'engage'
));
... lines 29 - 30
});
... lines 32 - 33
}
}

That's it! The reason we need to pass the User object as the first argument is so that the password encoder knows which encoder algorithm to use. Let's try it: find your terminal and reload the fixtures:

php bin/console doctrine:fixtures:load

You might notice that this is a bit slower now. By design, password encoding is CPU-intensive. Ok, check out the database!

php bin/console doctrine:query:sql 'SELECT * FROM user'

Awesome! Beautiful, encoded passwords. The bcrypt algorithm generated a unique salt for each user, which lives right inside this string.

Checking the Password

Ok, just one more step - and it's an easy one! We need to check the submitted password in LoginFormAuthenticator. This is the job of checkCredentials():

... lines 1 - 17
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
... lines 20 - 63
public function checkCredentials($credentials, UserInterface $user)
{
// only needed if we need to check a password - we'll do that later!
return true;
}
... lines 69 - 78
}

We already know which service can do this. Add one more argument to your constructor: UserPasswordEncoderInterface $passwordEncoder. Hit Alt+Enter to initialize that field:

... lines 1 - 9
use Symfony\Component\Security\Core\Encoder\UserPasswordEncoderInterface;
... lines 11 - 18
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
... lines 21 - 23
private $passwordEncoder;
public function __construct(UserRepository $userRepository, RouterInterface $router, CsrfTokenManagerInterface $csrfTokenManager, UserPasswordEncoderInterface $passwordEncoder)
{
... lines 28 - 30
$this->passwordEncoder = $passwordEncoder;
}
... lines 33 - 80
}

Then down in checkCredentials(), return $this->passwordEncoder->isPasswordValid() and pass this the User object and the raw, submitted password... which we're storing inside the password key of $credentials:

... lines 1 - 18
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
... lines 21 - 66
public function checkCredentials($credentials, UserInterface $user)
{
return $this->passwordEncoder->isPasswordValid($user, $credentials['password']);
}
... lines 71 - 80
}

And.. we're done! Time to celebrate by trying it! Move over, but this time put "foo" as a password. Login fails! Try engage. Yes!

Next: it's finally time to start talking about how we deny access to certain parts of our app. We'll start off that topic with a fun feature called access_control.

Leave a comment!

  • 2020-04-17 weaverryan

    Hey Pedro Hull!

    Excellent question :). Indeed, I see no problem with your implementation - checkCredentials() is a fine place for this and your logic looks perfect. Test this, then push it up to production - all +1 from me!

    Cheers!

  • 2020-04-17 Vladimir Sadicov

    Yeah! That will be great! Cheers and have a nice time of day!

  • 2020-04-17 Pedro Hull

    Thanks Vladimir Sadicov ! I definitely agree with you.
    To finish, i will also have to update some other features to use the new encoder (signup flow, form to change customer password).

  • 2020-04-17 Vladimir Sadicov

    Hey Pedro Hull

    Nice question! Honestly your implementation looks good, the only correction from my point of view is checking order. I'd prefer first to check against new encoder and then old for some performance reasons. If you look closer checking against new encoder will save 1 encoder run, and for old encoder there is no reasons to save think about performance because you will run update queries.

    Cheers!

  • 2020-04-15 Pedro Hull

    Assuming i'm using Symfony 3.4, i need to migrate some old hashed password to a new one. As the brand new migrate_from is not an option to this version, where would be a good place to put this logic?

    I do have only one Authenticator and i'm looking to put the logic inside checkCredentials().

    What about something like this implementation?


    public function checkCredentials($credentials, UserInterface $customer)
    {
    // Check plain password against 'old' encoder
    $isValidFromOldEncoder = $this->customPassEncoder->isPasswordValid($customer->getPassword(), $credentials['password'], $customer->getSalt());

    // Password valid from old Encoder
    if ($isValidFromOldEncoder) {
    // Upgrade current encoded password within the new ArgoEncoder
    $encoded = $this->argoEncoder->encodePassword($credentials['password'], $customer->getSalt());

    // TODO: move it to CustomerManager
    $customer->setPassword($encoder);
    $this->em->flush();

    return true;
    }

    // When password is not valid from old encoder, try it within the new ArgoEncoder
    return $this->argoEncoder->isPasswordValid($customer->getPassword(), $credentials['password'], $customer->getSalt());

    }

    Anything im missing?

  • 2020-01-22 Diego Aguiar

    Hey Michael

    You can't use any service inside an entity, you may find a hack to do it but the recommendation is to treat your entities as a data model only. However, you can set up a Doctrine listener to automatically encode a user password on creation or update. You can learn about Doctrine listeners here: https://symfony.com/doc/cur...

    Cheers!

  • 2020-01-21 Michael M.

    Hello everyone !
    A simple "logical or best pratice" question about the password encoder : is it possible to use it inside the User entity, directly in the setPassword() function ?
    Because you have to set up this encoder in every controllers, unit test or fixture test you need it... :(

    Cheers !

  • 2020-01-06 weaverryan

    Yo Mike !

    Happy new year! :) Nice digging through this - I think you identified everything perfectly: the "auto" mode will always use the "best" password encoder available and (yes) it looks like it was falling back to bcrypt on your production machine.

    > What a pity that PHP doesn't support the "latest" algorithms out of the box, only if you configure it manually to do so.

    Yea, that's true :/. So the story is that, starting in PHP 7.2, the lib Sodium extension DOES come "bundled with PHP". What that means is that you do not need to install it manually, but when you compile php (or when someone compiles php) they *do* need to have the --with-sodium flag to enable it. It sounds like your server (Ubuntu?) didn't do that by default - often you need to install it manually - e.g. apt install php-libsodium.

    Anyways, good job sorting this out! If I remember correctly, if you DID install libsodium, Symfony will automatically start using it for new users and (I think?) automatically "migrate" old passwords to use argon when those "old users" log in (that's when Symfony temporarily has the plain-text passwords and so can re-hash it via Argon). I haven't tried that functionality out yet though, so I'm not 100% sure if you need do to some extra work to get that migration part or not.

    Cheers!

  • 2020-01-01 Mike

    Hi SF Team, thank you for your outstanding work!

    Why is the password string different on my local machine vs my production server?
    (After a new user registration)

    Local machine password string in DB (PHP 7.4.1):

    $argon2id$v=19$m=65536,t=4,p=1$XWMkl2KbtwT0ROg6b+bRaw$LRHoTCUrVZ62wkuw3YWQgCmuumTYQXuoaHbfSTUIwMw

    Production machine password string in DB (PHP 7.4.1):

    $2y$13$vyDR81RZwiDlef4HMSZizuO9Ct4cYwUIs2kB28ayZUdVZGhdywdEG

    At first I thought the reason is the environment, defined inside the .env file, but that's not the case.
    The production server always creates passwords with this "type" of password string whereas the local machine always creates the other type of password string.

    Why is that? (Both have PHP 7.4.1)
    And is it important?
    (The local machine password string ($argon2id$...) could be better, because SF can detect which type of algorithm was used for future "password encryption upgrades"? (whereas this is not possible with the "short password string" the production server produces?)

    UDPATE://
    After some research I found out that the local PHP 7.4.1 was build with Sodium support and the production PHP 7.4.1 build doesn't have Sodium support.
    And the production server password "type" looks like a bcrypt string, correct?

    But why chooses SF bcrypt instead of the stronger argon2id hashing algorithm on the production server (which should be implemented in every PHP 7.4 build?)?
    The Symfony Docs tells me that it chooses argon2id over bcrypt if possible.
    Is this possibly a bug inside Symfony?

    My security.yaml of course contains this auto algorithm config:

    security:
    encoders:
    App\Entity\User:
    algorithm: auto

    Uodate2://
    After digging deeper, I found out that the production php build is configured without libsodium/argon2 support. Thats why I think SF falls back to bcrypt
    What a pity that PHP doesn't support the "latest" algorithms out of the box, only if you configure it manually to do so.

  • 2019-11-27 weaverryan

    Hey Abdessamad El-haouzi!'

    Good solve! This should NOT be necessary, but there is temporarily a bug in DoctrineBundle that is requiring you to clear your cache after any Doctrine "metadata" changes. Actually, the bug has been fixed - https://github.com/doctrine... - we just need to wait for version 1.12.1 or 2.0.1 of that bundle to be released :).

    Cheers!

  • 2019-11-27 Abdessamad El-haouzi

    solved!
    ./bin/console doctrine:cache:clear-result
    ./bin/console doctrine:cache:clear-query

  • 2019-11-27 Abdessamad El-haouzi

    Hello,
    I'm updated User entity by adding password field, but when i run "make:migration" command, i got this warning "[WARNING] No database changes were detected." after that, i deleted file migration manually but still same warning!

  • 2019-10-04 Victor Bocharsky

    Hey Dung,

    Glad yuo figured it out yourself, well done! Yeah, Symfony's web debug toolbar is the simplest and most powerful when you need to debug things in Symfony projects.

    Cheers!

  • 2019-10-04 Dung Le

    ooh, i found out that we have to logout first, by looking into user icon of Symfony debug bar I saw that i was still logged in as a user. Thanks anyway!

  • 2019-10-04 Dung Le

    Hello there,

    Not sure what went wrong, but I always get "Invalid credentials" not sure where to debug it, can you please point me?

    Thanks so much!

  • 2019-08-30 Diego Aguiar

    Hey Christina Vandendyck

    Yeah, you are technically correct but PHP allow you to call undefined methods on an object and since you already know that the user must be an instance of your entity user, then it should just work. Or you can do something like this just to be safer


    public function checkCredentials($credentials, UserInterface $user): bool
    {
    if (! $user instanceof User) {
    throw new \RuntimeException('Unknow user instance!');
    }

    // perform your check here
    }

    Another approach you can take is to just store your barcode under your password field because you won't be using real passwords right? The barcode IS your password

  • 2019-08-30 Christina Vandendyck

    Hey Diego Aguiar,

    I tried something similar but... $user is the UserInterface. My getBarcode function is under my User entity so of course, error :(

  • 2019-08-29 Diego Aguiar

    Hey Christina Vandendyck

    If you won't check the password anymore, then yes, you have to change the checkCredentials method and do your "barcode" check in there. Probably something like


    public function checkCredentials($credentials, UserInterface $user): bool
    {
    return $user->getBarcode() === $credentials['barcode'];
    }

    Cheers!

  • 2019-08-29 Christina Vandendyck

    Hi guys.

    I made similar LoginFormAuthenticator and it works really good.
    But my client ask for a change: the authentification is now with email and a barcode.

    Barcode is a similar property in my User entity: string of 6 char.
    So I made some changes.
    In short:

    > update the login form and change the password input and have the barcode
    > update the LoginFormAuthenticator:



    public function getCredentials(Request $request) {
    $credentials =
    [
    'email_address' => $request->request->get('email_address'),
    'barcode' => $request->request->get('barcode'),
    'csrf_token' => $request->request->get('_csrf_token')
    ];
    // ......
    }

    But when I try to login, it seems that it's still the password who is checked.
    I think I have to change some stuff in the checkCredentials function but I don't know what to do fo checking the combination email_adresse > barcode.

    Some help ?

  • 2019-07-03 Diego Aguiar

    Hey MarBod

    That's a good question and there is an elegant way to manage it. Give it a check to this docs and if you still have more questions let us know!
    https://symfony.com/doc/cur...

    Cheers!

  • 2019-07-03 MarBod

    Hello,
    how can I add a check, if the user is active?
    In my user class I have the field active. A login should only be possible, if active = true.

    Where I have to add this?

  • 2019-06-11 Victor Bocharsky

    Hey Sasha,

    Do you want to encode the password in setPassword() method? If so, it's a bad practice, because to encode passwords you need a special service, and injecting/passing the service into entities is not a good idea. Yes, you can use Doctrine event listener to listen, here's an example: https://symfonycasts.com/sc...

    Cheers!

  • 2019-06-11 Саша

    To encode my password in setPassword method, can i use doctrine listener from this tutorial?
    https://symfonycasts.com/sc...
    Or symfony 4 need to use another technic?

  • 2019-06-11 Diego Aguiar

    Hey @Sana

    If you are looking for an example you can watch this video from our security tutorial: https://symfonycasts.com/sc...

    I hope it helps you. Cheers!

  • 2019-06-09 sana

    Hello! How to encode password in User->setPassword? setPassword store only plain password in database

  • 2019-06-04 Victor Bocharsky

    Hey Giacomo,

    Yes, it should be possible with even listener where you can check what page user is on and tweak target path for him.

    > if the user is not active, it can't log

    If you're using Symfony Guard authenticator - as we do in this course - you can implement whatever logic you need, I'd do it in checkCredentials() method. You can throw a specific exception: CustomUserMessageAuthenticationException. We're talking about it in the end of the course: https://symfonycasts.com/sc... .

    Btw, TargetPathTrait is also covered in this course, see: https://symfonycasts.com/sc...

    So, I'd recommend you to complete this course to get more context about related things.

    Cheers!

  • 2019-06-03 Giacomo Balloccu

    Lovely that's why then! Can I do something like if the user come from 'this path' redirect to a page istead of the one he was trying to access?
    Also I need to modify the security and put:
    if the user is not active, it can't log

    Any ideas?

  • 2019-06-03 Victor Bocharsky

    Hey Giacomo,

    Redirects are pretty straightforward, but Symfony has a thing called TargetPathTrait that holds the previous URL from what you came to the Login page. It helps you to redirect users back to the same page where they were before came to the Login page for authentication. It's useful in almost all the cases, though in your case it returns you back to the confirm email page that's not a good idea. I think you can use that TargetPathTrait in your controller and call "saveTargetPath()" right before "return $this->redirectToRoute('app_login');" passing whatever URL you want users be redirected after successful login. Or just call "removeTargetPath()" and they will be redirected to the homepage IIRC. You can also debug things a bit with dump($this->getTargetPath()) at some points of your application.

    Sorry for the late reply!

    Cheers!

  • 2019-05-31 weaverryan

    And now, in Symfony 4.3, you can use this cool "auto" algorithm instead of argon2i or anything else: it will automatically choose the best hashing algorithm available :)

  • 2019-05-29 Giacomo Balloccu

    Hi! I have done the registration who send a confirmation token through email, but I still don't understand how redirect works..
    Check this:


    /**
    * @Route("/confirm/{token}", name="app_confirm_email")
    *
    */
    public function confirmRegistration($token, EntityManagerInterface $em, Request $request, UserPasswordEncoderInterface $passwordEncoder){
    $repositoryToken = $em->getRepository(Confirmationtoken::class);
    $repositoryUser = $em->getRepository(User::class);

    $form = $this->createForm(SetupFirstPasswordForm::class);
    $form->handleRequest($request);
    $confirmationtoken = $repositoryToken->findOneBy(['value' => $token]);
    if($confirmationtoken != null){
    $confirmedUser = $repositoryUser->findOneBy(['id' => $confirmationtoken->getAssociatedUser()]);

    if ($form->isSubmitted() && $form->isValid()) {

    $confirmedUser->setPassword($passwordEncoder->encodePassword(
    $confirmedUser,
    $form['password']->getData()
    ));
    $confirmedUser->setActive(true);

    $em->persist($confirmedUser);
    $em->flush();

    $em->remove($confirmationtoken);
    $em->flush();

    $this->addFlash('success', 'Password Impostata con successo!');
    return $this->redirectToRoute('app_login');
    }

    return $this->render('account/setfirstpassword.html.twig', [
    'form' => $form->createView(),
    'token' => $token,
    ]);

    }

    After the setup of the first password I get to login thanks to the redirect but when i press login I get redirected to https://localhost:8000/account/confirm/12345678
    Why?

  • 2019-05-16 Peter Tsiampas

    Hey Marc, Yeah I solved the problem because i wasn't actually returning the password value for comparison. I had to hunt down the code (because I have done so much since then!). The user object didn't have a return statement on the getPassword method (don't ask, I have no idea why this happened). Once I did that it all worked fine.

    Not sure if that helps.

  • 2019-05-15 Vladimir Sadicov

    Hey Marc Poggi

    It's not bad, it's awesome, that you found how to solve your issue. Stay in touch if you have more issues.

    Cheers!

  • 2019-05-15 Marc Poggi

    Wow ! I did not read all the comments , and I finally found while debugging getPassword() never implemented .
    My bad .

  • 2019-05-15 Marc Poggi

    Hi Peter , I got the same issue, and I tried to compare the encoded password on two sides ... which is not workable since I read weaverryan comments and salt keeps changing when encoding...
    So at the moment I keep stuck ... any progress on your side ?
    Thanks Marc

  • 2019-03-12 Victor Bocharsky

    Hey Mike,

    If you're on the newest PHP 7.3 - yes, use PASSWORD_ARGON2ID. See related RFC: https://wiki.php.net/rfc/ar... - it looks like Argon2 Password Hash Enhancements.

    Cheers!

  • 2019-03-12 Mike

    You said that Argon2i is recommended for PHP 7.2=<


    security:
    encoders:
    App\Entity\User:
    algorithm: argon2i


    Since Argon2id is implemented into PHP 7.3, is Argon2id now the recommended algorithm?

  • 2019-02-26 Diego Aguiar

    Hey Christina Vandendyck

    That's the normal behavior after a successful login in. Symfony automatically redirects you to the target path

    Cheers!

  • 2019-02-25 Christina Vandendyck

    Strange... Just after the post, I have a 302...

  • 2019-02-11 weaverryan

    Hey Rob!

    Woh! That is super strange! And... ya know... probably shouldn't happen ;). So let's see what we can figure out:

    A) First, do you see a stack trace when you run our of memory? I'd like to see *where* the error is happening. If you don't see a stack trace (you only see the error), installing XDebug might help.

    B) When you say "My browser locks up" - what do you mean exactly? Does it really freeze or lock up? Or just a 500 error?

    My first instinct is that there is possibly some accidental recursion (e.g. you're calling the same method that you're inside of) - but that's just a wild guess. I would try commenting out some code until you can get the memory error to go away - so that we can figure out where it's coming from!

    Let me know what you find out!

    Cheers!

  • 2019-02-09 Rob

    Hi SymfonyCasts Crew!

    I was rolling along perfect with Symfony Security: Beautiful Authentication, Powerful Authorization until Chapter 12 - Checking the User’s Password.

    When I set up the password field in the User entity and try the Login functions, I’m getting the PHP Fatal error in PhpStorm: Allowed memory size of 268435456 bytes exhausted (tried to allocators 262144 bytes …. Blah blah fun stuff! My browser locks up with HTTP 500 error…!

    I know has nothing with the tutorial code but rather a problem with my AMP setup, but I’m wondering if you might have some tips on how to correct for this error. I’m on iMac with Mohave running PHP version 7.1.19. My php.ini has memory_limit set to 256mb and using PhpStorm with built in server.

    Not sure if anyone has run across this type of memory error but any ideas for a fix would be welcome! Thanks in advance! Rob

  • 2019-01-08 Diego Aguiar

    Hmm, interesting. Which command are you running? Try re-creating your whole DB

  • 2019-01-08 mike

    Actually my table is empty anyhow.

  • 2019-01-07 Diego Aguiar

    Hey @mike

    The thing is that you already have some users loaded in your DB, so you can't add a new "not nullable" field to that table, you have to truncate it first (If it were a production table, then, you would have to do a three steps migration: add column, update existing records with a default value, alter column to not nullable)

    Cheers!

  • 2019-01-07 mike

    Hi,
    the faker isn't filling the database and also this error is being shown
    An exception occurred while executing 'ALTER TABLE user ADD COLUMN password VARCHAR(255) NOT NULL':

    SQLSTATE[HY000]: General error: 1 Cannot add a NOT NULL column with default value NULL
    while following exactly your steps

  • 2018-12-31 Diego Aguiar

    Hey Nassim Bennouna

    We're glad to know that you are liking our tutorials :)

    Back to your question, the logout functionality is handled by Symfony by default but you have to activate it, you only have to specify the logout option to `true` (the quick way)


    // config/packages/securityl.yaml
    security:
    firewalls:
    main:
    logout: true

    You can find more info at the docs: https://symfony.com/doc/cur...

    Cheers & Happy new year!!

  • 2018-12-29 Nassim Bennouna

    Hello !
    First things first, THANK YOU for all your work, it is just awesome !

    Now the question ;-)
    Is it me missing something or we actually do not logout, when reaching login, nor on failed login attempt ?
    Especially if there is already a session for the failed email ?
    I tried to invalidate session but it appears to be a abd idea as it makes fail the csrf check

    So , what do you think is the best way to handle that ?

    Thank you in advance for your advice !

  • 2018-11-16 Peter Tsiampas

    Well now I feel a little silly! My schedule was cleared so I started to debug this problem.

    It would probably help if was actually returning the value from getPassword() inside the user controller. Mind you with your help, it was pretty easy to debug when I started to drill down.

    Thanks Ryan

  • 2018-11-09 christianstrang

    It worked for me as well and my assumption is, that Symfony will check the type of hashing algorithm used by the password-hash stored in the database ($2y$13 for bcrypt) and then use this encoder instead and will use the argon2i only for newly created user passwords. It also worked in the opposite direction (changing the encoders back from argon2i to bcrypt).

    This is quite nice, so you can use bcrypt now and if you update your encoders later to argon2i, your bcrypt-passwords will still work. However, you should still upgrade the bcrypt passwords to the new algorithm after a successful login (at this point you have the cleartext password and can upgrade the hash using argon2i without the user even noticing).

  • 2018-11-08 weaverryan

    Hey Peter Tsiampas!

    > I was having a "WHaaaaaT" moment.

    LOL. That makes *perfect* sense :D. So, you're kinda right - there IS some extra crazy stuff happening inside the encode function: the "salt" is being auto-generated FOR you. Each time you say "encode the password 1234", argon2i (and also bcrypt) generates a new, random salt, uses THAT to hash the password, and then the salt is stored inside the encoded string itself. So yes, every time you encode, you will get a different result. When the password validity is checked, internally, the salt is "read" from the encoded password, and the 1234 is encoded using that *exact* salt. It's hard to notice this because, from the outside, you never see anything related to the salt. But, under the hood, encode always generates a new salt and the "is this password valid" function is smart enough to encode the submitted password using the *existing* salt.

    That doesn't necessarily solve your problem... but hopefully you will have less WHaaaaaT moments ;).

    And thanks for the SUPER nice note! I'm SO happy you like the tone. Learning this stuff is a lot of work, but it's also fun to unlock everything!

    Cheers!

  • 2018-11-07 Diego Aguiar

    Awesome! Let's keep learning :D

  • 2018-11-07 Victor Le Fourn

    I finally figured out what the problem was !
    I just forgot to override the getPassword method.
    Now it works perfectly :)

  • 2018-11-07 Victor Le Fourn

    Hi Diego !
    I re-run the command doctrine:fixtures:load and checked that each user had a password and a username but when I try to dump($user->getPassword()) in the checkCredentials function, I get null as a response.

  • 2018-11-06 Peter Tsiampas

    What I was doing is a dump of the encoded password (which is simple like 1234) then I was seeing what was being stored in the database and they were both different.

    I know with hashes that when you use the same salt+password it will always give you back the same hash, so feeding the encode function the same values, I expected it to always be the same, but it kept changing! Which was doing my head in and was having a "WHaaaaaT" moment.

    The only other thing I can think of is the encode function is including something extra like say "salt+password+userid" or something crazy like that, good for security, bad for my brain if I can't see it.

    I will do some more research using the tools you mentioned above and see what I have done wrong.

    Thanks for the reply Ryan

    Also on a personal note! I love your screen casts, I don't know how you do it keeping such an awesome happy delivery of content every screen cast, but that's what keeps me subscribed to your stuff

  • 2018-11-06 Diego Aguiar

    Hey Victor Le Fourn

    Did you run the fixtures? Could you double check that the user credentials you are submitting exist on the Database?

    Cheers!

  • 2018-11-06 weaverryan

    Hey Peter Tsiampas!

    Ah, interesting! Debugging these issues can be a pain - because... all the passwords are encrypted, so it's tough to see what's going on!

    > the password keeps changing (meaning the encoded password for the match)

    Where are you seeing this exactly? Are you looking in this function? https://github.com/symfony/... I'm asking because, as you can see, WE never see the plaintext password get encoded and then compared directly to the one in the database (this is on purpose, it can cause timing attacks). We just see the , for example, \Sodium\crypto_pwhash_str_verify($encoded, $raw) method called, which handles all of this behind the scenes.

    Anyways, when I hit these situations, I sometimes use an online tool - like https://argon2-generator.com/ - to help me figure out what's going on. You could use the "Decrypt" to see if the hash in the database matches the expected plain password. Oh, and by the way, if you use the "Encrypt" functionality to encrypt a plain text password, it WILL be different every time you do this. That's because Argon creates a unique "salt" each time, and this is stored inside the hash itself. When we check to see if a plain password matches this, the hashed password's salt is read, and this salt is used to encrypt the plain password. THEN the values will match.

    Let me know what you find out!

    Cheers!

  • 2018-11-06 Victor Le Fourn

    I have an authenticator problem.
    When I try different passwords in my login page, none of them passes the authenticator, even with "engage".

    I tried to copy and paste the code for LoginFormAuthenticator from the folder "finish" but it still doesn't work.
    Can you help me ?

  • 2018-11-06 Peter Tsiampas

    I am having an odd problem with the argon2i algorithm, clearly I must of missed something but I checked all the code pieces and they seem correct.

    $this->passwordEncoder->isPasswordValid($user, $credentials['password']);

    Keeps reporting false, I did some digging to see what was going on and the password keeps changing (meaning the encoded password for the match) so it never matches.

    Has anyone else run into this?

  • 2018-10-19 Victor Bocharsky

    Hey Serge,

    Ah, really, "final class" thing, thanks sharing this information with others!

    Cheers!

  • 2018-10-19 Serge Boyko

    Good guess, but unfortunately all of them have this line...

    After spending some time digging this issue I found the defining difference!
    Files with that "white thing" have "final class" keyword in them.

  • 2018-10-19 Victor Bocharsky

    Hey Serge,

    Can't you find differences between migrations with that white thing and ones without it? :) I suppose in those last 2 migrations you have "declare(strict_types=1);", but not sure 100%.

    Cheers!

  • 2018-10-19 Serge Boyko

    Question about PhpStorm.
    Do you know what this white thing in the top left corner of two latest migration files mean?
    https://www.dropbox.com/s/c...

  • 2018-10-08 weaverryan

    Hey Ahmad Mayahi!

    Hmmm, yes they should stop working :). Here is the "flow" and why it should not work:

    1) You configure bcrypt to be used
    2) You then create a few users (e.g. via the fixtures, but it doesn't matter). These password field on these users is now a bcrypt-encoded salt+string
    3) You change to argon2i
    4) When you try to login, the password encode (which will now be using argon2i) will fail to decode your password.

    Are you sure you didn't reload the fixtures after changing the algorithm? I could totally be wrong about the above "flow", but I'm *pretty* sure that there's not any magic where argon2i can understand the the bcrypt algorithm. Let me know!

    Cheers!

  • 2018-10-07 Ahmad Mayahi

    I changed the algorithm from bcrypt to argon2i, but the existing logins still work, shouldn't they stop?

  • 2018-09-26 Peter Kosak

    Thanks I have missed it. I will shift my logic there.

  • 2018-09-26 Victor Bocharsky

    Hey Peter,

    As you understand by yourself, checkCredentials() is far from an ideal place to do so :) So yes, I'd better do it in onAuthenticationSuccess(). However, you're not correct about the fact you can't get logged in user inside it, take a look at $token variable that implements TokenInterface. If you look at it, you will find getUser() method, so you can just call: "$token->getUser()" in onAuthenticationSuccess() to get current logged in user, and then you can set lastLoginDate on it and flush(), i.e. you don't need to pass the user with setLoggedInUser() method between methods.

    Cheers!

  • 2018-09-26 Peter Kosak

    Hello, it's me
    I was wondering if after all these years you'd like to meet
    To go over everything.

    Sorry, I couldnt help myself :-D but reminds me hello song from adele anyway.

    I just want to double check if this is a proper approach and if its ok to have more logic inside of checkCredentials method.

    I would like to update last login date for user; only if credentials are correct so I am thinking to have something like this:


    public function checkCredentials($credentials, UserInterface $user)
    {
    if($this->passwordEncoder->isPasswordValid($user, $credentials['password'])){
    $user = $this->manager->getRepository(User::class)->findOneBy([
    'id' => $user->getId()
    ]);
    $user->setLastLoginDate(new \DateTime());
    $this->manager->persist($user);
    $this->manager->flush();
    $this->setLoggedInUser($user);
    return true;
    }
    return false;
    }


    this works but then I realise there is


    public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey)
    {
    dd($this->getLoggedInUser());
    return new RedirectResponse($this->router->generate('welcome'));
    }


    this method that would be actually better place to have it because I dont have to check if user pw is valid but also I could query user object in order to redirect user to correct route based on his preferences.

    It is strange that user has been authenticated but there is no easy way to access his properties easily from onAuthenticationSuccess method so I have to setLoggedInUser($user) in checkCredential() and then getLoggedInUser() in authenticationSuccess but there is getUser method that will return user but then we need to pass credential so it starting to be complicated and left me confused.

    So the question: is my approach correct to update last login date for authenticated users and the way of getting user object into onAuthenticationSuccess method?

  • 2018-09-24 Victor Bocharsky

    Hey Stephane!

    Ah, good catch! I fixed it in https://github.com/knpunive...

    Thank you for reporting this misprint!

    Cheers!

  • 2018-09-22 Stéphane

    Hello,

    You forget the n in $this->passwordEcoder->encodePassword()