Pare-feu Symfony : connexion par formulaire et déconnexion

Le pare-feu de Symfony, déclaré dans security.yaml, identifie qui fait la requête ; les règles access_control décident ensuite si elle peut passer.

security:
    firewalls:
        main:
            lazy: true
            provider: employes
            form_login:
                login_path: app_connexion
                check_path: app_connexion
                enable_csrf: true
            logout:
                path: app_deconnexion
                target: app_accueil
    access_control:
        - { path: ^/cuisine, roles: ROLE_CUISINIER }

Le pare-feu intercepte le formulaire envoyé à check_path, retrouve l'utilisateur par son provider, vérifie le mot de passe haché, ouvre la session et renvoie vers la page demandée : le contrôleur de connexion se contente d'afficher le formulaire, avec getLastUsername() et getLastAuthenticationError() d'AuthenticationUtils. La déconnexion est elle aussi interceptée, la route app_deconnexion n'est jamais exécutée. Symfony choisit un seul pare-feu par requête, le premier dont le pattern correspond. Le piège : le pare-feu n'intercepte que l'envoi en POST vers check_path. Un formulaire qui poste ailleurs n'authentifie personne, et la page se réaffiche sans un mot ; une page de connexion protégée par sa propre règle d'accès tourne en boucle de redirections.

Les exercices font fermer la cuisine de la taverne au public, avec un utilisateur en mémoire au mot de passe haché, la connexion par formulaire et la déconnexion, puis réparer une API sabotée où, entre autres, les guildes reçoivent une page de connexion HTML au lieu de leur réservation.