Bonjour popotte,
Oui, pour le formulaire et la function en-dessous de ma route "login", c'est bon. J'ai tout pareil pour le front et le controller. En revanche, je n'avais pas la même chose dans le security.yalm. J'ai ajouté ce qui manquait, puis j'ai testé. Malheureusement, ça n'a rien changé. Après avoir essayé de me connecter (avec les bons identifiants enregistrés dans ma base de données) je suis toujours redirigée vers ma page login, comme si je n'avais pas essayé d'entrer avec des identifiants...
J'ai discuté de ce problème avec une des mes camarades de la formation (qui a le même problème avec le login). Elle est étonnée de ne voir apparaître aucune erreur, car normalement les erreurs devraient aussi s'afficher si mes identifiants ne sont pas trouvés par exemple dans la base de données... Du coup, je cherche des hypothèses pour savoir "Pourquoi ça ne fonctionne pas ?".
Je suis tombée sur cet article. Je me suis dis que peut-être il y a un problème avec SerializableInterface, mais je n'ai pas trouvé cette classe dans mon code. (Désolée, c'est en anglais) :
Understanding how Users are Refreshed from the Session
At the end of every request (unless your firewall is stateless), your User object is serialized to the session. At the beginning of the next request, it's deserialized and then passed to your user provider to "refresh" it (e.g.Doctrine queries for a fresh user).
Then, the two User objects (the original from the session and the refreshed User object) are "compared" to see if they are "equal". By default, the core AbstractToken class compares the return values of the getPassword(), getSalt () and getUserIdentifier () methods. If any of these are different, your user will be logged out. This is a security measure to make sure that malicious users can be de-authenticated if core user data changes.
However, in some cases, this process can cause unexpected authentication problems. If you're having problems authenticating, it could be that you are authenticating successfully, but you immediately lose authentication after the first redirect.
In that case, review the serialization logic (e.g. SerializableInterface) on you user class (if you have any) to make sure that all the fields necessary are serialized.