👍

Imo the context listener should rather not try to use all user providers to refresh the user, but should only use the user provider that was configured for the active firewall.

@xabbuh Agreed. But the question still remain when there is no provider configured for the firewall, doesn't it?

@einenlum It should then use the first configured user provider like it's done elsewhere.

This is very optimistic solution :P If you have 3 providers and you need the 3th, then the first two will query, fetch or something their backends on every page load. For example 3 query per page load just to refresh the user... and can be worse if you have rest api providers or anything else slow.

And the continue doesn't do anything there, if you just use that exception (UnsupportedException) then you are doing the same thing :)

Checking the firewall's provider is tricky too, because:

1. It seems very hard to check which firewall are we in. In 3.2 there is a new FirewallConfig or FirewallContext class which may help, dont know.
2. The firewall may have a provider key, but one firewall may have more than one authentication method which can overwrite that provider key. For example form_login and basic may have distinct providers in the same firewall, if someone like suffering.

So you don't really know, which method (provider) the user came from.

The only solution would be to save the provider in the token or user, but as fabpot said in the connected issue, it was there once, and they removed it for unkown reasons. Changing the tokeninterface would be big bc break, so no much hope :P

Note that BC breaks are not allowed, so you'll need another approach if you need this in the core.

closing in favour of#21791

@einenlum Can you check if#21865 fixes your issue?