Flag of Ukraine
SymfonyCasts stands united with the people of Ukraine
TRACK

Symfony 4 >

COURSE

Symfony Security: Beautiful Authentication, Powerful Authorization

Buy Access to Course

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
Previous Chapter

Next Chapter
Edit on GitHub

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:

118 lines src/Entity/User.php
... 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:

29 lines src/Migrations/Version20180831181732.php
... 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:

130 lines src/Entity/User.php
... 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:

130 lines src/Entity/User.php
... 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():

130 lines src/Entity/User.php
... 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:

130 lines src/Entity/User.php
... 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():

130 lines src/Entity/User.php
... 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:

130 lines src/Entity/User.php
... 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:

44 lines config/packages/security.yaml
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:

36 lines src/DataFixtures/UserFixture.php
... 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:

36 lines src/DataFixtures/UserFixture.php
... 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():

36 lines src/DataFixtures/UserFixture.php
... 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:

36 lines src/DataFixtures/UserFixture.php
... 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():

80 lines src/Security/LoginFormAuthenticator.php
... 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:

82 lines src/Security/LoginFormAuthenticator.php
... 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:

82 lines src/Security/LoginFormAuthenticator.php
... 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!

Most Useful Newest Oldest
72
Login or Register to join the conversation
Default user avatar
Default user avatar Pedro Hull | posted 3 years ago | edited

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?

1 Reply
sadikoff Avatar

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!

1 Reply
Default user avatar
Default user avatar Pedro Hull | sadikoff | posted 3 years ago | edited

Thanks sadikoff ! 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).

Reply
sadikoff Avatar

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

Reply
weaverryan Avatar

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!

Reply
Christina V. Avatar
Christina V. Avatar Christina V. | posted 3 years ago | edited

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.
<b>In short:</b>

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 ?

1 Reply
MolloKhan Avatar

Hey Christina V.

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!

Reply
Christina V. Avatar
Christina V. Avatar Christina V. | MolloKhan | posted 3 years ago | edited

Hey MolloKhan,

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

Reply
MolloKhan Avatar

Hey Christina V.

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

Reply
Farshad Avatar
Farshad Avatar Farshad | posted 2 years ago

I copied over the code from BaseFixture and UserFixture from the source code to my own project. at UserFixture.php it says:
use App\Entity\ApiToken. Undifined ApiToken. Is the path outdated?

Reply
Victor Avatar

Hey Farry7,

Did you forget to copy/paste namespace as well? Add "use App\Entity\ApiToken" in your BaseFixture and UserFixture files. Otherwise, could you share the exact error message? It would help to find the problem better.

Cheers!

Reply
Angelika R. Avatar
Angelika R. Avatar Angelika R. | posted 2 years ago

Why does symfony not support pepper? Would that be inconvenient? If I would like to have two spices, one global, should I write my own encoder based on one of standard encoders or is there some other approach more recommended?

Reply
Angelika R. Avatar

I have read some advice to not use the peppers because bcrypt was not meant for this (and because of other reasons), so I probably won't do it.

Reply
MolloKhan Avatar

I think the best thing you can do is to always use the newest encryption algorithm and use the Symfony's mechanism to migrate all passwords
You can read more about it here https://symfony.com/doc/cur...

Cheers!

1 Reply
Default user avatar
Default user avatar Michael M. | posted 3 years ago

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 !

Reply
MolloKhan Avatar

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!

2 Reply
Mike P. Avatar
Mike P. Avatar Mike P. | posted 3 years ago

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.

Reply
weaverryan Avatar

Yo Mike P. !

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!

Reply
Abdessamad E. Avatar
Abdessamad E. Avatar Abdessamad E. | posted 3 years ago

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!

Reply
Abdessamad E. Avatar

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

Reply
weaverryan Avatar

Hey Abdessamad E.!'

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!

Reply
Dung L. Avatar
Dung L. Avatar Dung L. | posted 3 years ago

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!

Reply
Dung L. Avatar

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!

Reply
Victor Avatar

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!

Reply
Markus B. Avatar
Markus B. Avatar Markus B. | posted 4 years ago

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?

Reply
MolloKhan Avatar

Hey Markus B.

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!

Reply
Default user avatar

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

Reply
MolloKhan Avatar

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!

Reply
Default user avatar

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?

Reply
Victor Avatar

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!

Reply
Gballocc7 Avatar

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?

Reply
Victor Avatar

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!

1 Reply
Gballocc7 Avatar

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?

Reply
Victor Avatar

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!

1 Reply
Mike P. Avatar
Mike P. Avatar Mike P. | posted 4 years ago | edited

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?

Reply
Victor Avatar

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!

Reply
weaverryan Avatar

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 :)

Reply
Christina V. Avatar
Christina V. Avatar Christina V. | posted 4 years ago

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

Reply
MolloKhan Avatar

Hey Christina V.

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

Cheers!

Reply
Robert V. Avatar
Robert V. Avatar Robert V. | posted 4 years ago

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

Reply
weaverryan Avatar

Hey Robert V.!

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!

-1 Reply
Default user avatar

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

Reply
MolloKhan Avatar

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!

Reply
Default user avatar

Actually my table is empty anyhow.

Reply
MolloKhan Avatar

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

Reply
Nassim bennouna Avatar
Nassim bennouna Avatar Nassim bennouna | posted 4 years ago

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 !

Reply
Victor L. Avatar
Victor L. Avatar Victor L. | posted 4 years ago

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 ?

Reply
MolloKhan Avatar

Hey Victor L.

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

Cheers!

Reply
Victor L. Avatar

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

Reply
MolloKhan Avatar

Awesome! Let's keep learning :D

Reply
Load more comments
Cat in space

"Houston: no signs of life"
Start the conversation!

Symfony 4

What PHP libraries does this tutorial use?

// composer.json
{
    "require": {
        "php": "^7.1.3",
        "ext-iconv": "*",
        "composer/package-versions-deprecated": "^1.11", // 1.11.99
        "knplabs/knp-markdown-bundle": "^1.7", // 1.7.0
        "knplabs/knp-paginator-bundle": "^2.7", // v2.8.0
        "knplabs/knp-time-bundle": "^1.8", // 1.8.0
        "nexylan/slack-bundle": "^2.0,<2.2.0", // v2.0.0
        "php-http/guzzle6-adapter": "^1.1", // v1.1.1
        "sensio/framework-extra-bundle": "^5.1", // v5.2.0
        "stof/doctrine-extensions-bundle": "^1.3", // v1.3.0
        "symfony/asset": "^4.0", // v4.1.4
        "symfony/console": "^4.0", // v4.1.4
        "symfony/flex": "^1.0", // v1.17.6
        "symfony/framework-bundle": "^4.0", // v4.1.4
        "symfony/lts": "^4@dev", // dev-master
        "symfony/orm-pack": "^1.0", // v1.0.6
        "symfony/security-bundle": "^4.0", // v4.1.4
        "symfony/serializer-pack": "^1.0", // v1.0.1
        "symfony/twig-bundle": "^4.0", // v4.1.4
        "symfony/web-server-bundle": "^4.0", // v4.1.4
        "symfony/yaml": "^4.0", // v4.1.4
        "twig/extensions": "^1.5" // v1.5.2
    },
    "require-dev": {
        "doctrine/doctrine-fixtures-bundle": "^3.0", // 3.0.2
        "easycorp/easy-log-handler": "^1.0.2", // v1.0.7
        "fzaninotto/faker": "^1.7", // v1.8.0
        "symfony/debug-bundle": "^3.3|^4.0", // v4.1.4
        "symfony/dotenv": "^4.0", // v4.1.4
        "symfony/maker-bundle": "^1.0", // v1.7.0
        "symfony/monolog-bundle": "^3.0", // v3.3.0
        "symfony/phpunit-bridge": "^3.3|^4.0", // v4.1.4
        "symfony/profiler-pack": "^1.0", // v1.0.3
        "symfony/var-dumper": "^3.3|^4.0" // v4.1.4
    }
}
Edit on GitHub
Previous Chapter
Next Chapter
userVoice