InMy.Live

Revenons aux fonctionnalités de Laravel 5.2, voulez-vous ? 5.2 a introduit une augmentation significative de la puissance de l’ensemble du système d’authentification, notamment en simplifiant considérablement l’exécution simultanée de plusieurs “gardes”.

Pourquoi devriez-vous vous en soucier ?

Le garde d’authentification par défaut dans Laravel avant 5.2 (maintenant nommé le web guard) est votre couche d’authentification d’application Web traditionnelle : le nom d’utilisateur et le mot de passe sont envoyés à un contrôleur, qui vérifie les informations d’identification et les redirige si elles ne sont pas valides ; si elles sont valides, les informations de l’utilisateur sont enregistrées dans la session. Toutes ces pièces ne sont pas absolument nécessaires, mais c’est l’état d’esprit général.

Mais que se passe-t-il si vous souhaitez qu’une API s’exécute dans la même application et qu’elle utilise des jetons Web JSON (ou un autre mécanisme d’authentification sans état et sans session) ? Dans le passé, vous deviez franchir de nombreuses étapes pour que plusieurs pilotes d’authentification s’exécutent en même temps.

Les gardes d’authentification par défaut de Laravel 5.2

Dans la version 5.2, non seulement il est simple d’avoir plusieurs pilotes d’authentification en cours d’exécution, mais cela fonctionne déjà de cette façon dès la sortie de la boîte.

Si vous cochez config/auth.phpvous verrez deux protections prêtes à l’emploi : webqui est la couche d’authentification classique de Laravel, et apiqui est un pilote basé sur des jetons sans état (pas de mémoire de session).

Les deux, comme vous pouvez le voir, se connectent au même “fournisseur”.

Les fournisseurs d’authentification sont également personnalisables. Ils définissent la manière dont le système doit stocker et récupérer les informations sur vos utilisateurs. Chacun est défini par une instance de Illuminate\Contracts\Auth\UserProvider.

    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],

        'api' => [
            'driver' => 'token',
            'provider' => 'users',
        ],
    ],

Si vous regardez plus haut dans config/auth.php, vous pouvez voir que la protection Auth par défaut sera “web”. Cela signifie que chaque fois que vous utilisez des fonctions d’authentification, des intergiciels ou des façades dans votre application, ils prendront par défaut la valeur web garde sauf si vous spécifiez explicitement le contraire.

Présentation du pilote d’authentification de jeton

Donc si web utilise le classique session chauffeur, qu’est-ce que c’est nouveau token pilote que nous voyons alimenter le api garde?

Jacob Bennett a déjà écrit un article fantastique à ce sujet : API Token Authentication in Laravel 5.2.

Consultez son article pour en savoir plus sur son fonctionnement, mais voici le résumé :

• Ajouter un api_token colonne à votre users tableau. Chaîne de 60 caractères, unique.
• Au lieu d’utiliser le auth middleware dans votre définition de route, utilisez le auth:api middleware.
• Dans vos routes d’API, utilisez Auth::guard('api')->user() pour obtenir votre utilisateur au lieu de Auth::user().

Comme vous pouvez le voir, nous devons stocker un api_token pour chaque utilisateur, et chaque demande entrante protégée par le token-conduit api guard nécessitera un paramètre de requête nommé api_token avec un jeu de jetons d’API valide pour authentifier cet utilisateur. Et comme il est sans état, chaque requête devra avoir ce jeton d’API défini ; une requête réussie n’affectera pas la requête suivante.

Si vous n’êtes pas familier avec l’authentification basée sur les jetons, l’application consommatrice (par exemple, une application iOS) aura obtenu et enregistré le jeton de l’utilisateur qui s’authentifie avant cette demande, elle créera donc ses appels d’API à l’aide de ce jeton dans le cadre de l’URL. Par exemple, une application iOS peut vouloir obtenir une liste des amis de son utilisateur ; lorsque l’utilisateur a authentifié l’application pour la première fois avec votre site Web/API, l’application a reçu un jeton et l’a stocké. Désormais, il générera des requêtes à l’aide d’URL comme celle-ci : http://yourapp.com/api/friends?api_token=STORED_TOKEN_HERE

Utilisation de pilotes autres que ceux par défaut

Comme vous pouvez le voir dans l’exemple de jeton ci-dessus, nous allons utiliser deux pilotes principaux autres que ceux par défaut : dans le middleware auth guard et lorsque nous utilisons des fonctionnalités pratiques telles que Auth::check() et Auth::user() dans notre code.

Vous pouvez choisir le garde que vous utilisez pour protéger vos itinéraires en ajoutant deux-points et le nom du garde après auth dans la clé middleware (par exemple Route::get('whatever', ['middleware' => 'auth:api'])).

Vous pouvez choisir quel garde vous appelez manuellement dans votre code en faisant guard('guardname') le premier appel d’une chaîne fluide à chaque fois que vous utilisez la façade Auth (ex. Auth::guard('api')->check()).

Créer vos propres gardes et chauffeurs

Créer votre propre garde est simple, car chaque garde n’est qu’une clé (web, api) qui pointe vers une configuration spécifique d’un pilote (session, token) et un fournisseur (users). Ils sont configurés, comme mentionné ci-dessus, dans config/auth.php:

    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],

        'api' => [
            'driver' => 'token',
            'provider' => 'users',
        ],
        'matts-fancy-api-guard' => [
            'driver' => 'token',
            'provider' => 'users',
        ],
    ],

Mais comme vous pouvez le constater, cela ne fait pas grand-chose à moins que vous ne changiez de pilote ou de fournisseur.

Créer votre propre pilote n’est pas aussi simple que créer votre propre garde. Les docs ont un endroit sur la création de votre propre pilote d’authentification, et vous allez essentiellement créer votre propre implémentation de Illuminate\Contracts\Auth\Guard puis l’enregistrer en tant que conducteur chez un fournisseur de services quelque part.

La documentation explique également comment créer votre propre fournisseur d’utilisateurs.

Concludinal

C’est ça. Apprécier.