Buy Access to Course
08.

Authentication Errors

Share this awesome video!

|

Keep on Learning!

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

Login Subscribe

Go back to the login page. I wonder what happens if we fail the login... which, is only possible right now if we use a non-existent email address. Oh!

Cannot redirect to an empty URL

Filling in getLoginUrl()

Hmm: this is coming from AbstractFormLoginAuthenticator our authenticator's base class. If you dug a bit, you'd find out that, on failure, that authenticator class is calling getLoginUrl() and trying to redirect there. And, yea, that makes sense: if we fail login, the user should be redirected back to the login page. To make this actually work, all we need to do is fill in this method.

No problem: return $this->router->generate('app_login'):

61 lines | src/Security/LoginFormAuthenticator.php
// ... lines 1 - 13
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
// ... lines 16 - 55
protected function getLoginUrl()
{
return $this->router->generate('app_login');
}
}

Ok, try it again: refresh and... perfect! Hey! You can even see an error message on top:

Username could not be found.

We get that exact error because of where the authenticator fails: we failed to return a user from getUser():

61 lines | src/Security/LoginFormAuthenticator.php
// ... lines 1 - 13
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
// ... lines 16 - 39
public function getUser($credentials, UserProviderInterface $userProvider)
{
return $this->userRepository->findOneBy(['email' => $credentials['email']]);
}
// ... lines 44 - 59
}

In a little while, we'll learn how to customize this message because... probably saying "Email" could not be found would make more sense.

The other common place where your authenticator can fail is in the checkCredentials() method:

61 lines | src/Security/LoginFormAuthenticator.php
// ... lines 1 - 13
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
// ... lines 16 - 44
public function checkCredentials($credentials, UserInterface $user)
{
// only needed if we need to check a password - we'll do that later!
return true;
}
// ... lines 50 - 59
}

Try returning false here for a second:

// ...
    public function checkCredentials($credentials, UserInterface $user)
    {
        return false;
    }
// ...

Then, login with a legitimate user. Nice!

Invalid credentials.

Anyways, go change that back to true:

61 lines | src/Security/LoginFormAuthenticator.php
// ... lines 1 - 13
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
// ... lines 16 - 44
public function checkCredentials($credentials, UserInterface $user)
{
// only needed if we need to check a password - we'll do that later!
return true;
}
// ... lines 50 - 59
}

How Authentication Errors are Stored

What I really want to find out is: where are these errors coming from? In SecurityController, we're getting the error by calling some $authenticationUtils->getLastAuthenticationError() method:

28 lines | src/Controller/SecurityController.php
// ... lines 1 - 6
use Symfony\Component\Security\Http\Authentication\AuthenticationUtils;
class SecurityController extends AbstractController
{
// ... lines 11 - 13
public function login(AuthenticationUtils $authenticationUtils)
{
// get the login error if there is one
$error = $authenticationUtils->getLastAuthenticationError();
// ... lines 18 - 21
return $this->render('security/login.html.twig', [
// ... line 23
'error' => $error,
]);
}
}

We're passing that into the template and rendering its messageKey property... with some translation magic we'll talk about soon too:

32 lines | templates/security/login.html.twig
// ... lines 1 - 10
{% block body %}
<form class="form-signin" method="post">
{% if error %}
<div class="alert alert-danger">{{ error.messageKey|trans(error.messageData, 'security') }}</div>
{% endif %}
// ... lines 16 - 29
</form>
{% endblock %}

The point is: we magically fetch the "error" from... somewhere and render it. Let's demystify that. Go back to the top of your authenticator and hold command or control to click into AbstractFormLoginAuthenticator.

In reality, when authentication fails, this onAuthenticationFailure() method is called. It's a bit technical, but when authentication fails, internally, it's because something threw an AuthenticationException, which is passed to this method. And, ah: this method stores that exception onto a special key in the session! Then, back in the controller, the lastAuthenticationError() method is just a shortcut to read that key off of the session!

So, it's simple: our authenticator stores the error in the session and then we read the error from the session in our controller and render it:

28 lines | src/Controller/SecurityController.php
// ... lines 1 - 8
class SecurityController extends AbstractController
{
// ... lines 11 - 13
public function login(AuthenticationUtils $authenticationUtils)
{
// get the login error if there is one
$error = $authenticationUtils->getLastAuthenticationError();
// ... lines 18 - 25
}
}

The last thing onAuthenticationFailure() does is call our getLoginUrl() method and redirect there.

Filling in the Last Email

Go back to the login form and fail authentication again with a fake email. We see the error... but the email field is empty - that's not ideal. For convenience, it should pre-fill with the email I just entered.

Look at the controller again. Hmm: we are calling a getLastUsername() method and passing that into the template:

32 lines | templates/security/login.html.twig
// ... lines 1 - 10
{% block body %}
<form class="form-signin" method="post">
// ... lines 13 - 18
<input type="email" name="email" id="inputEmail" class="form-control" placeholder="Email address" required autofocus>
// ... lines 20 - 29
</form>
{% endblock %}

Oh, but I forgot to render it! Add value= and print last_username:

32 lines | templates/security/login.html.twig
// ... lines 1 - 10
{% block body %}
<form class="form-signin" method="post">
// ... lines 13 - 18
<input type="email" value="{{ last_username }}" name="email" id="inputEmail" class="form-control" placeholder="Email address" required autofocus>
// ... lines 20 - 29
</form>
{% endblock %}

But... we're not quite done. Unlike the error message, the last user name is not automatically stored to the session. This is something that we need to do inside of our LoginFormAuthenticator. But, it's super easy. Inside getCredentials(), instead of returning, add $credentials = :

69 lines | src/Security/LoginFormAuthenticator.php
// ... lines 1 - 14
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
// ... lines 17 - 32
public function getCredentials(Request $request)
{
$credentials = [
'email' => $request->request->get('email'),
'password' => $request->request->get('password'),
];
// ... lines 39 - 45
}
// ... lines 47 - 67
}

Now, set the email onto the session with $request->getSession()->set(). Use a special key: Security - the one from the Security component - ::LAST_USERNAME and set this to $credentials['email']:

69 lines | src/Security/LoginFormAuthenticator.php
// ... lines 1 - 14
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
// ... lines 17 - 32
public function getCredentials(Request $request)
{
$credentials = [
'email' => $request->request->get('email'),
'password' => $request->request->get('password'),
];
$request->getSession()->set(
Security::LAST_USERNAME,
$credentials['email']
);
// ... lines 44 - 45
}
// ... lines 47 - 67
}

Then, at the bottom, return $credentials:

69 lines | src/Security/LoginFormAuthenticator.php
// ... lines 1 - 14
class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
// ... lines 17 - 32
public function getCredentials(Request $request)
{
$credentials = [
'email' => $request->request->get('email'),
'password' => $request->request->get('password'),
];
$request->getSession()->set(
Security::LAST_USERNAME,
$credentials['email']
);
return $credentials;
}
// ... lines 47 - 67
}

Try it! Go back, login with that same email address and... nice! Both the error and the last email are read from the session and displayed.

Next: let's learn how to customize these error messages. And, we really need a way to logout.