Le Middleware
Middleware vous permet d’intercepter les demandes et les réponses et d’injecter des comportements de manière dynamique chaque fois qu’une page ou un point de terminaison est sur le point d’être rendu. Ce rendu a lieu au moment de la construction pour toutes les pages pré-rendues, mais il a lieu lorsque la route est demandée pour les pages rendues à la demande, rendant disponible des fonctionnalités SSR supplémentaires telles que les cookies et les en-têtes (EN).
Le middleware vous permet également de définir et de partager des informations spécifiques aux requêtes entre les points de terminaison et les pages en modifiant un objet locals
disponible dans tous les composants Astro et les points de terminaison de l’API. Cet objet est disponible même lorsque ce middleware s’exécute au moment de la construction.
Utilisation basique
Titre de la section Utilisation basique-
Créez
src/middleware.js|ts
(Alternativement, vous pouvez créersrc/middleware/index.js|ts
.) -
Dans ce fichier, exportez une fonction
onRequest()
à laquelle on peut passer un objetcontext
et une fonctionnext()
. Il ne doit pas s’agir d’une exportation par défaut. -
Dans n’importe quel fichier
.astro
, accédez aux données de réponse en utilisantAstro.locals
.
Objet context
Titre de la section Objet contextL’objet context
inclut des informations à mettre à disposition d’autres middleware, routes API et routes .astro
pendant le processus de rendu.
C’est un argument optionnel passé à onRequest()
qui peut contenir l’objet locals
ainsi que toutes les propriétés additionnelles à partager pendant le rendu.Par exemple, l’objet context
peut inclure les cookies utilisés pour l’authentification.
Stocker des données dans context.locals
Titre de la section Stocker des données dans context.localscontext.locals
est un objet pouvant être manipulé dans le middleware.
Cet objet locals
est transmis à travers le processus de traitement des requêtes et est disponible en tant que propriété pour APIContext
et AstroGlobal
. Cela permet de partager des données entre les middlewares, les routes API et les pages .astro
. Ceci est utile pour stocker des données spécifiques à une requête, telles que les données de l’utilisateur, à travers l’étape de rendu.
Les Integrations peuvent définir des propriétés et fournir des fonctionnalités à travers l’objet locals
. Si vous utilisez une intégration, vérifiez sa documentation pour vous assurer que vous ne surchargez aucune de ses propriétés et que vous ne faites pas de travail inutile.
Vous pouvez stocker n’importe quel type de données dans locals
: des chaînes, des nombres, et même des types de données complexes tels que des fonctions et des cartes.
Vous pouvez ensuite utiliser ces informations dans n’importe quel fichier .astro
avec Astro.locals
.
locals
est un objet qui vit et meurt au sein d’une seule route Astro ; lorsque la page de votre route est rendue, locals
n’existera plus et un nouvel objet sera créé. Les informations qui doivent persister à travers plusieurs requêtes de pages doivent être stockées ailleurs.
La valeur de locals
ne peut pas être modifiée à l’exécution. Cela risquerait d’effacer toutes les informations stockées par l’utilisateur. Astro effectue des vérifications et génère une erreur si la valeur de locals
est remplacée.
Exemple : Supprimer des informations sensibles
Titre de la section Exemple : Supprimer des informations sensiblesL’exemple ci-dessous utilise un middleware pour remplacer “PRIVATE INFO” par le mot “REDACTED” afin de vous permettre d’afficher le code HTML modifié sur votre page :
Type de middleware
Titre de la section Type de middlewareVous pouvez importer et utiliser la fonction utilitaire defineMiddleware()
pour bénéficier de la sécurité de type :
A la place, si vous utilisez JsDoc pour profiter de la sécurité des types, vous pouvez utiliser MiddlewareHandler
:
Pour activer les types pour les informations contenues dans Astro.locals
, ce qui vous donne l’autocomplétion dans les fichiers .astro
et le code middleware, déclarez un espace de noms global dans le fichier env.d.ts
:
Ensuite, dans le fichier du middleware, vous pouvez tirer parti de l’autocomplétion et de la sécurité des types.
Enchaînement middleware
Titre de la section Enchaînement middlewarePlusieurs middlewares peuvent être reliés dans un ordre précis à l’aide de séquence()
:
L’ordre de la console sera alors le suivant :
Réécriture
Titre de la section Réécriture
Ajouté à la version :
astro@4.13.0
L’APIContext
expose une méthode appelée rewrite()
qui fonctionne de la même manière que Astro.rewrite.
Utilisez context.rewrite()
dans un middleware pour afficher le contenu d’une autre page sans rediriger votre visiteur vers une nouvelle page. Cela déclenchera une nouvelle phase d’affichage, entraînant la ré-exécution de tout middleware.
Vous pouvez également passer à la fonction next()
un paramètre optionnel de chemin URL pour réécrire la Request
courante sans réenclencher une nouvelle phase de rendu. L’emplacement du chemin de réécriture peut être fourni sous la forme d’une chaîne, d’une URL ou d’une Request
:
La fonction next()
accepte la même charge utile que la fonction Astro.rewrite()
. L’emplacement du chemin de réécriture peut être fourni sous la forme d’une chaîne, d’une URL ou d’une Request
.
Quand vous avez plusieurs fonctions middleware enchaînées via sequence(), soumettre un chemin à next()
réécrira la Request
en place et le middleware ne s’exécutera pas à nouveau. Le middleware suivant dans la chaîne recevra la nouvelle Request
avec son context
mis à jour :
L’appel de next()
avec cette signature créera un nouvel objet Request
en utilisant l’ancien ctx.request
. Cela signifie que toute tentative de consommation de Request.body
, avant ou après cette réécriture, générera une erreur d’exécution. Cette erreur est souvent générée avec les actions Astro qui utilisent des formulaires HTML. Dans ces cas, nous vous recommandons de gérer les réécritures de vos modèles Astro à l’aide de Astro.rewrite()
au lieu d’utiliser un middleware.
Pages d’erreur
Titre de la section Pages d’erreurLe middleware tentera de s’exécuter pour toutes les pages rendues à la demande, même lorsqu’un itinéraire correspondant ne peut être trouvé. Cela inclut la page 404 par défaut (vide) d’Astro et toutes les pages 404 personnalisées. Cependant, c’est à l’adaptateur (EN) de décider si ce code s’exécute. Certains adaptateurs peuvent servir une page d’erreur spécifique à la plate-forme à la place.
Le middleware tentera également de s’exécuter avant de servir une page d’erreur 500, y compris une page 500 personnalisée, sauf si l’erreur du serveur s’est produite lors de l’exécution du middleware lui-même. Si votre middleware ne s’exécute pas correctement, vous n’aurez pas accès à Astro.locals
pour rendre votre page 500.