Comme son nom l'indique, le middleware intercepte et traite les données des requêtes, vérifie les données et détermine s'il convient d'autoriser l'accès au middleware suivant après un traitement logique entre les requêtes et les réponses.
Le middleware est divisé en middleware de préfixe et middleware de post-fin ; il peut être utilisé pour l'authentification des autorisations, la journalisation, etc. (apprentissage recommandé : Programmation PHP du débutant au maître)
Le middleware fournit un mécanisme pratique pour filtrer les requêtes HTTP entrant dans l'application. Par exemple, Laravel dispose d'un middleware intégré pour vérifier l'authentification des utilisateurs. Si l'utilisateur ne réussit pas l'authentification d'identité, le middleware redirigera l'utilisateur vers l'interface de connexion. Cependant, si l'utilisateur est authentifié, le middleware autorisera la requête plus loin dans l'application.
Laravel fournit automatiquement le middleware VerifyCsrfToken pour toutes les applications de routage Lorsque la requête HTTP entre dans l'application et passe par le middleware VerifyCsrfToken, le jeton sera vérifié pour empêcher la falsification de demande intersite, ainsi que la réponse. sera ajouté avant que la réponse HTTP ne quitte l'application. (À partir de Laravel 5.5, le middleware CSRF n'est automatiquement appliqué qu'au routage Web)
Bien sûr, en plus de l'authentification d'identité, vous pouvez également écrire d'autres middleware pour effectuer diverses tâches. Par exemple : le middleware CORS peut être chargé d'ajouter des informations d'en-tête appropriées à toutes les réponses quittant l'application ; le middleware de journalisation peut enregistrer toutes les demandes entrant dans l'application.
Pourquoi avez-vous besoin d'un middleware ?
1. Scénarios dans lesquels un middleware n'est pas requis
Lorsque nous développons un projet d'externalisation relativement petit, notre première considération est de savoir comment terminer rapidement le projet et le livrer. plutôt que d'envisager ses futures mises à niveau et extensions, et que la logique métier n'est pas très compliquée, nous pouvons alors compléter tout le code métier avec un seul contrôleur (contrôleur), ce qui ne pose pas de problème, mais lorsque nous créons une logique métier, c'est plus compliqué Et le projet ?
2. Scénarios nécessitant un middleware
Lorsque la logique métier est complexe, il n'est pas approprié d'écrire tout le code métier dans le contrôleur, car le contrôle Le serveur sera très volumineux et difficile à maintenir. À l'heure actuelle, nous devons superposer la structure (contrôleur auxiliaire de service, modèle auxiliaire d'actions et de référentiels, que je mentionnerai dans un autre article) et écrire des opérations de cookies/vérification des autorisations des utilisateurs et d'autres opérations. . dans leur middleware respectif, afin que la maintenabilité des projets que nous écrivons soit grandement améliorée.
Ordre d'exécution du middleware ?
1. Pourquoi le middleware a-t-il une séquence d'exécution
Scénario hypothétique : L'utilisateur supprime un commentaire. . Une fois le commentaire supprimé avec succès, il doit être enregistré dans le journal des opérations de cette entreprise.
Processus d'exécution (seul le processus principal est pris en compte) : Entrée (index.php) > Vérifier la connexion (middleware 1) > Enregistrer les données (middleware 2) > log (middleware 3) >
Pourquoi y a-t-il trois middlewares au lieu de deux middlewares ci-dessus ? La réponse est que l'enregistrement des logs généraux des opérations ne peut pas être réalisé par un middleware (vous pouvez essayer de réfléchir à la manière d'implémenter un middleware séparément).
Vérifiez si l'utilisateur est connecté : middleware 1 ; enregistrer le journal des opérations commerciales : middleware 2 + middleware 3 ; si ces trois middlewares ne distinguent pas l'ordre d'exécution, l'exigence ne peut pas être réalisée, c'est pourquoi Middleware aura un ordre d'exécution.
2. Pré-middleware et post-middleware
Voici ce que sont le pré-middleware et le post-middleware.
Pré-middleware : middleware qui est exécuté avant que l'application ne traite la demande métier (contrôleur), comme le middleware 1 et le middleware 2 dans l'exemple ci-dessus.
Post-middleware : middleware qui est exécuté après que l'application ait traité la requête métier (contrôleur), correspondant au middleware 3.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!