Avec la commande make:auth

Dépréciation

La commande make:auth est dépréciée. Passer directement au chapitre suivant si vous souhaitez juste créer un formulaire de login.

Vous pouvez lire cette page si vous voulez connaître l'ancienne structure et la configuration appliquée avec make:auth

Maintenant que nous disposons d'utilisateurs dans notre base de données, il faut pouvoir les authentifier.

Tout comme nous avons exécuté la commande make:user, on va pouvoir exécuter une autre commande make:auth en choisissant Form Login pour générer automatiquement un formulaire de login et un Authenticator.

Les pare-feux (firewalls)

Quand on exécute cette commande, le Maker va automatiquement inscrire notre authentification derrière un pare-feu nommé main :

config/packages/security.yaml

security:
  firewalls:
    dev:
      pattern: ^/(_(profiler|wdt)|css|images|js)/
      security: false
    main:
      lazy: true
      provider: app_user_provider
      custom_authenticator: App\Security\AppAuthenticator
      logout:
        path: app_logout

Les pare-feux, ou firewalls, permettent tout simplement de filtrer les requêtes entrantes.

"dev"

Le pare-feu dev est uniquement là pour autoriser l'affichage du profiler et de la Web Debug Toolbar, que nous voyons en bas de notre écran lors de nos développements, avec diverses informations sur la requête/page courante

On retrouve donc dans notre firewall main : l'authenticator, et le provider à utiliser pour les utilisateurs.

Et lazy ?

la directive lazy permet de n'utiliser la session PHP, pour charger l'utilisateur, que si on en a effectivement besoin. Cela peut être utile si on a besoin de vérifier les rôles de l'utilisateur, par exemple. Mais ce n'est pas toujours le cas.

L'authenticator

La commande make:auth a donc généré et enregistré dans custom_authenticator une classe App\Security\AppAuthenticator.

Si nous nous rendons dans cette classe, on constate qu'elle hérite d'une classe abstraite AbstractLoginFormAuthenticator. C'est une classe fournie par Symfony pour nous permettre d'accélérer les développements. Elle contient déjà une implémentation par défaut qui nous conviendra pour ce que nous voulons faire.

Notre Authenticator contient une méthode authenticate, qui va être tout simplement chargée de réaliser l'authentification à partir de la requête entrante (objet Request).

Les passeports

Ce mécanisme d'authentification va être réalisé et validé grâce à la création d'un Passport, qui va être retourné à l'appelant.

Un Passport contiendra l'utilisateur qui va s'authentifier, ainsi que quelques informations, comme le mot de passe à vérifier, ou encore le token CSRF à valider.

Ici, notre Passport va contenir trois informations :

public function authenticate(Request $request): Passport
{
    $email = $request->request->get('email', '');

    $request->getSession()->set(Security::LAST_USERNAME, $email);

    return new Passport(
        new UserBadge($email),
        new PasswordCredentials($request->request->get('password', '')),
        [
            new CsrfTokenBadge('authenticate', $request->request->get('_csrf_token')),
        ]
    );
}

UserBadge

Le UserBadge, construit à partir d'un identifiant utilisateur, servira à récupérer l'utilisateur avec le provider associé.

Dans la configuration du composant security (config/packages/security.yaml), on peut voir que pour le pare-feu main, là où nous avons positionné notre AppAuthenticator, le provider (donc fournisseur d'utilisateurs) configuré est app_user_provider.

Dans les providers déclarés, il s'agit bien du fournisseur créé par le maker lorsqu'on a exécuté la commande make:user : c'est bien ce fournisseur qui saura aller chercher un utilisateur par son email.

Credentials

Les Credentials sont simplement les informations d'identification (ici le mot de passe). Pour les valider, on peut imaginer que le mot de passe entré dans le formulaire sera confronté au hash se trouvant en base de données

CsrfTokenBadge

Ensuite, le Passport pourra éventuellement contenir, comme on le voit dans notre Authenticator, des badges supplémentaires venant ajouter d'autres types de données (ici le fait d'intégrer la gestion d'un jeton CSRF).

Le but du Passport va donc être de valider les différents Badge ou Credentials qu'on lui a fournis.

Par exemple, le UserBadge va aller chercher un utilisateur. S'il n'est pas trouvé (email inexistant), alors le badge ne sera pas résolu, pas validé. Ensuite, s'il a trouvé l'utilisateur, il va tenter de valider les Credentials, puis le jeton CSRF, etc...si tous les badges sont validés, alors l'authentification a réussi.