AbstractLoginFormAuthenticator y redireccionamiento a la URL anterior

Hey Mahmut,

Are you sure the error you see is related to the code you showed above? :) Because that code looks good to me, probably you have another spot in your app where you generate app_main_homepage route without parameters? Please, double-check it. You can easily debug it with dd() before and after that route generation:

dd('before');
$this->router->generate('app_main_homepage', ['username' => $username])
dd('after');

Make sure you hit "before" spot first, then comment it out and make sure you hit the "after". Also, probably you generate route that shows the error on the redirected page? I would recommend you to search for app_main_homepage globally in your project to see if there are any spots where you forgot that mandatory parameter. If everything looks good - hm, maybe try to clear the cache just in case, sometimes it helps!

Also, make sure that the $username you're passing to generate() is not null or empty string :)

Cheers!

hello Victor,

I found the problem, ı was missing the parameter to path ( app_main_homepage). I added and fixed.

Hey Mahmut,

Great! Easy fix :)

Hey MattWelander!

Happy new year! This is an excellent question. Take this logic out of your authenticator and instead, add it to an event subscriber on the CheckPassportEvent::class event. The PasswordCredentials themselves are actually checked via a listener on this event: https://github.com/symfony/symfony/blob/6.3/src/Symfony/Component/Security/Http/EventListener/CheckCredentialsListener.php - you can use it as a guide. To be sure that you're running AFTER the password check, you could set your priority to -1 for this subscriber - so like this:

public static function getSubscribedEvents(): array
{
    return [CheckPassportEvent::class => ['checkPassport', -1]];
}

Let me know if that works out! Btw, a side effect of this (which is probably good) is that if you have any other ways for a user to authenticate (including, iirc, via a "remember me cookie"), those will also be "subject" to this check. In other words, no matter how your user tries to log in, if they fail this check, they will fail authentication. If this is NOT what you want (and you only want this check to happen for this ONE authenticator), that's no problem. Do this:

A) Create a new badge class - e.g. CheckDenyFormLoginBadge. It can basically be empty
B) Add this to your Passport
C) In your subscriber, only run the check if this badge is present.

Cheers!

Hey Andrea Gelmini !

It look like you have a tiny error in your first code example. This is how we do the supports() check

    public function supports(Request $request): ?bool
    {
        return ($request->getPathInfo() === '/login' && $request->isMethod('POST'));
    }

You can notice we hardcode the "/login" string

Cheers!

I'm confused =)

At one stage in this script you say:
"This means that... oh yea... we can remove code! Let's see: delete supports(), onAuthenticationFailure() and also start():"

In the resulting example, the method supports() is completely erased. Like Andrea Gelmini says above, this causes the authenticator to go completely disconnect. the login form is no longer attached to an authenticator, submitting the form will only render the login form anew.

By your answer to Andrea above, it seems that you confirm that the supports() method should still be in the LoginFormAuthenticator? Was it a mistake to tell us to remove it alltogether and the script needs amending? Or is there something in mine and Andreas environment that is configured differently than in your environment, causing the supports() method from the AbstractLoginFormAuthenticator to go disconnect?

Hmm, I see what you mean. Let me clarify what's going on. I think you likely already know some of this, but just to clear everything up:

A) Every authenticator DOES need a supports() method.
B) But, when we extend AbstractLoginFormAuthenticator, you can remove the supports() method in your class, simply because it already exists in the parent class.

So yes, I think Diego's comment was not quite right.

Now, to the real question:

Or is there something in mine and Andreas environment that is configured differently than in your environment, causing the supports() method from the AbstractLoginFormAuthenticator to go disconnect?

Yes, possibly :). For some reason, the supports() method that you're inheriting is returning false when it should return true. You could add some debugging code to that method to find out why, though I might have an idea: are you running your site at the root of a domain - e.g. http://127.0.0.1:8000 is your homepage? Or is it under a subdirectory - e.g. http://127.0.0.1:8000/site is the homepage? If it is the latter, there is a known bug in that inherited method that makes it not match correctly. In that case, you should keep your supports() method so it works. Wow, and apparently I opened that issue - lol - https://github.com/symfony/symfony/issues/44893 - and it's fixed in Symfony 5.4.13, 6.0.14, 6.1.6 and 6.2.0 and higher.

Anyways, that was just a guess at the problem. If I'm wrong, I'd love to know what you find going wrong in that parent supports() method!

Cheers!

That was in fact a pretty good guess - I'm testing it off of http://localhost:8888/mysite/ 😂 thanks

Yay! Well then I'm double glad that this will, at least, be fixed in later versions!

Have fun!