> Symfony 5 > Symfony 5 Security: Authenticators
Login to bookmark this video
Buy Access to Course
20.

More form_login Config

|

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

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

Login Subscribe

Using form_login isn't as flexible as a custom authenticator class... though a lot of stuff can be configured.

For example, right now, it's not checking our CSRF token. Enable that by saying enable_csrf: true:

54 lines | config/packages/security.yaml
security:
// ... lines 2 - 16
firewalls:
// ... lines 18 - 20
main:
// ... lines 22 - 24
form_login:
// ... lines 26 - 29
enable_csrf: true
// ... lines 31 - 54

That's it! Over in the options, when you enable CSRF protection, it looks for a hidden field called _csrf_token with the string authenticate used to generate it. Fortunately, in our template, we're already using both of those things... so this is just going to work.

Seeing the Full List of Options

And there are even more ways we can configure this. Remember: to get this config, I ran debug:config security... which shows your current configuration, including defaults. But not all options are shown here. To see a full list, run config:dump security.

symfony console config:dump security

Instead of showing your actual config, this shows a huge list of example config. This is a much bigger list... here's form_login. A lot of this we saw before... but success_handler and failure_handler are both new. You can search the docs for these to learn how to control what happens after success or failure.

But also, later, we're going to learn about a more global way of hooking into the success or failure process by registering an event listener.

Rendering "last_username" On the Login Form

Anyways, we're not using our LoginFormAuthenticator anymore, so feel free to delete it.

And... I have good news! The core authenticator is doing one thing that our class never did! Up in authenticate()... this calls getCredentials() to read the POST data. Let me search for "session"... yup! This took me into getCredentials(). Anyways, after grabbing the submitted email - in this code that's stored as $credentials['username'] - it saves that value into the session.

It's doing that so that if authentication fails, we can read that and pre-fill the email box on the login form.

Let's do it! Go to our controller: src/Controller/SecurityController.php. This AuthenticationUtils has one other useful method. Pass a new variable to the template called last_username - you can call it last_email if you'd like - set to $authenticationUtils->getLastUsername():

31 lines | src/Controller/SecurityController.php
// ... lines 1 - 9
class SecurityController extends AbstractController
{
// ... lines 12 - 14
public function login(AuthenticationUtils $authenticationUtils): Response
{
return $this->render('security/login.html.twig', [
// ... line 18
'last_username' => $authenticationUtils->getLastUsername(),
]);
}
// ... lines 22 - 29
}

Once again, this is just a helper to read a specific key off of the session.

Now, in the template - login.html.twig - up here on the email field, add value="{{ last_username }} ":

39 lines | templates/security/login.html.twig
// ... lines 1 - 4
{% block body %}
<div class="container">
<div class="row">
<div class="login-form bg-light mt-4 p-4">
<form method="post" class="row g-3">
// ... lines 10 - 15
<div class="col-12">
// ... line 17
<input type="email" name="email" id="inputEmail" class="form-control" value="{{ last_username }}" required autofocus>
</div>
// ... lines 20 - 33
</form>
</div>
</div>
</div>
{% endblock %}

Cool! If we go to /login... it's already there from filling out the form a minute ago! If we enter a different email... yes! That sticks too.

Next: let's get back to authorization by learning how to deny access in a controller... in a number of different ways.