Si vous avez mis à jour vos projets depuis Symfony 5.3+, vous avez dû faire vos adieux à notre vieil ami Guard. Le composant Security a été entièrement repensé. Au début, j'avoue, j'ai un peu pesté en lisant la doc. Mais une fois le concept assimilé, c'est un pur bonheur d'architecture.
Pourquoi ce changement ?
L'ancien système était monolithique. Le nouveau est basé sur des événements et sépare clairement "qui est l'utilisateur" de "comment on vérifie ses credentials".
Le cœur du réacteur : L'Authenticator et le Passport
Aujourd'hui, quand vous créez un Custom Authenticator, la méthode clé n'est plus getUser() ou checkCredentials(). Tout se passe dans la méthode authenticate() qui doit retourner un Passport.
Un Passport, c'est comme un vrai passeport à l'aéroport. Il contient l'identité de l'utilisateur, et des tampons (les Badges) qui prouvent qu'il a le droit de passer.
public function authenticate(Request $request): Passport
{
$email = $request->request->get('email', '');
$password = $request->request->get('password', '');
return new Passport(
new UserBadge($email),
new PasswordCredentials($password),
[
new CsrfTokenBadge('authenticate', $request->request->get('_csrf_token')),
new RememberMeBadge(),
]
);
}
La puissance des Badges
Regardez le code ci-dessus. Vous voulez ajouter la protection CSRF ? Bam, on ajoute un CsrfTokenBadge. Vous voulez activer le "Se souvenir de moi" ? Bam, un RememberMeBadge. C'est du plug-and-play architectural.
Ne réinventez pas la roue
Avant de coder votre propre Authenticator, rappelez-vous que Symfony fournit nativement form_login, json_login, et même des solutions pour les liens magiques (Magic Links) ou l'authentification sans mot de passe (WebAuthn). Le Custom Authenticator ne doit être utilisé que si vous avez un besoin métier très spécifique (comme vous connecter via une API externe legacy).
Astuce de pro : Utilisez toujours la commande php bin/console make:auth pour générer le squelette, ça vous évitera d'oublier des méthodes de base (comme le onAuthenticationSuccess).
