Configurer Azure Static Web Apps

Article
03/11/2023

Vous pouvez définir la configuration d’Azure Static Web Apps dans le fichier staticwebapp.config.json, qui contrôle les paramètres suivants :

Routage
Authentification
Autorisation
Règles de secours
Remplacement des réponses HTTP
Définitions globales d’en-tête HTTP
Types MIME personnalisés
Mise en réseau

Remarque

routes.jssur qui a été précédemment utilisé pour configurer le routage est déconseillé. Utilisez staticwebapp.config.jssur tel que décrit dans cet article pour configurer le routage et d’autres paramètres pour votre application web statique.

Ce document décrit comment configurer Azure Static Web Apps, qui est un produit autonome et distinct de la fonctionnalité d’hébergement de sites web statiques de Stockage Azure.

Emplacement du fichier

L’emplacement recommandé pour le fichier staticwebapp.config.json est le dossier défini comme app_location dans le fichier de workflow. Toutefois, vous pouvez placer le fichier dans n’importe quel sous-dossier dans le dossier défini comme le app_location. En outre, s’il existe une étape de génération, vous devez vous assurer que l’étape de génération génère le fichier à la racine de l’output_location.

Pour plus de détails, consultez l’exemple de fichier config.

Important

Le fichier routes.json déconseillé est ignoré si un fichier staticwebapp.config.json existe.

Itinéraires

Vous pouvez définir des règles pour un ou plusieurs itinéraires dans votre application web statique. Les règles d’itinéraire vous permettent de restreindre l’accès aux utilisateurs de rôles spécifiques ou d’effectuer des actions telles que la redirection ou la réécriture. Les itinéraires sont définis sous forme de tableau de règles d’acheminement. Pour obtenir des exemples d’utilisation, consultez l’exemple de fichier config.

Les règles sont définies dans le tableau routes, même en présence d’un seul itinéraire.
Les règles sont évaluées dans l’ordre dans lequel elles apparaissent dans le tableau routes.
L’évaluation de la règle s’arrête à la première correspondance. Une correspondance se produit lorsque la propriété route et une valeur dans le tableau methods (si spécifié) correspondent à la requête. Chaque demande peut correspondre au plus à une règle.

Les problèmes de routage chevauchent de manière significative les concepts d’authentification (identification de l’utilisateur) et d’autorisation (attribution de capacités à l’utilisateur). Lisez le Guide d’authentification et d’autorisation, ainsi que cet article.

Définir des itinéraires

Chaque règle est composée d’un modèle d’itinéraire, ainsi que d’une ou plusieurs des propriétés facultatives de la règle. Les règles de routage sont définies dans le tableau routes. Pour obtenir des exemples d’utilisation, consultez l’exemple de fichier config.

Important

Seules les propriétés route et methods (si elles sont spécifiées) sont utilisées pour déterminer si une règle correspond à une demande.

Propriété de la règle	Requis	Valeur par défaut	Commentaire
`route`	Oui	n/a	Modèle d’itinéraire demandé par l’appelant. Les caractères génériques sont pris en charge à la fin des chemins d’accès d’itinéraire. Par exemple, l’itinéraire /admin* correspond à n’importe quel itinéraire sous le chemin d’accès /admin.
`methods`	Non	Toutes les méthodes	Définition d’un tableau de méthodes de demande qui correspondent à un itinéraire. Les méthodes disponibles sont notamment : `GET`, `HEAD`, `POST`, `PUT`, `DELETE`, `CONNECT`, `OPTIONS`, `TRACE` et `PATCH`.
`rewrite`	Non	n/a	Définit le fichier ou le chemin d’accès retourné par la demande. S’exclut réciproquement d’une règle `redirect`. Les règles de réécriture ne modifient pas l’emplacement du navigateur. Les valeurs doivent être relatives à la racine de l’application.
`redirect`	Non	n/a	Définit la destination de redirection du fichier ou du chemin d’accès pour une requête. S’exclut réciproquement d’une règle `rewrite`. Les règles de redirection modifient l’emplacement du navigateur. Le code de réponse par défaut est un code `302` (redirection temporaire), mais vous pouvez le remplacer par un code `301` (redirection permanente).
`statusCode`	Non	`301` ou `302` pour les redirections	Code d’état HTTP de la réponse.
`headers`	Non	n/a	Ensemble d’en-têtes HTTP ajoutés à la réponse. Les en-têtes spécifiques à l’itinéraire remplacent `globalHeaders` lorsque l’en-tête spécifique à l’itinéraire est le même que l’en-tête global dans la réponse. Pour supprimer un en-tête, définissez la valeur sur une chaîne vide.
`allowedRoles`	Non	anonyme	Définit un tableau de noms de rôles requis pour accéder à un itinéraire. Les caractères valides sont `a-z`, `A-Z`, `0-9` et `_`. Le rôle intégré, `anonymous`, s’applique à tous les utilisateurs. Le rôle intégré `authenticated` s’applique à tous les utilisateurs connectés. Les utilisateurs doivent appartenir à au moins un rôle. Les rôles sont mis en correspondance sur une base OU. Si un utilisateur se trouve dans l’un des rôles de la liste, l’accès est accordé. Les utilisateurs individuels sont associés à des rôles par le biais des invitations.

Chaque propriété a un objectif spécifique dans le pipeline de demande/réponse.

Objectif	Propriétés
Faire correspondre les itinéraires	`route`, `methods`
Traiter après la mise en correspondance et l’autorisation d’une règle	`rewrite` (modifie la demande) `redirect`, `headers`, `statusCode` (modifie la réponse)
Autoriser après la mise en correspondance d’un itinéraire	`allowedRoles`

Spécification de modèles d’itinéraire

La propriété route peut être un itinéraire exact ou un modèle de caractère générique.

Itinéraire exact

Pour définir un itinéraire exact, placez le chemin d’accès complet du fichier dans la propriété route.

{
  "route": "/profile/index.html",
  "allowedRoles": ["authenticated"]
}

Cette règle met en correspondance les demandes pour le fichier /profile/index.html. Étant donné que index.html est le fichier par défaut, la règle correspond également aux demandes pour le dossier (/profile ou /profile/).

Important

Si vous utilisez un chemin d’accès au dossier (/profile ou /profile/) dans la propriété route, il ne correspondra pas aux demandes du fichier /profile/index.html. Quand vous protégez un itinéraire qui dessert un fichier, utilisez toujours le chemin d’accès complet du fichier, par exemple /profile/index.html.

Modèle de caractère générique

Les règles de caractères génériques correspondent à toutes les requêtes d’un modèle d’itinéraire et sont uniquement prises en charge à la fin d’un chemin d’accès. Pour obtenir des exemples d’utilisation, consultez l’exemple de fichier config.

Par exemple, pour implémenter des itinéraires pour une application de calendrier, vous pouvez réécrire toutes les URL qui se trouvent sous l’itinéraire calendrier pour un seul fichier.

{
  "route": "/calendar*",
  "rewrite": "/calendar.html"
}

Le fichier calendar.html peut ensuite utiliser le routage côté client pour offrir une vue différente des variantes d’URL, comme /calendar/january/1, /calendar/2020 et /calendar/overview.

Remarque

Un modèle d’itinéraire de /calendar/* correspond à toutes les demandes sous le chemin d’accès /calendar/. Toutefois, il ne correspond pas aux demandes pour les chemins /calendar ou /calendar.html. Utilisez /calendar* pour mettre en correspondance toutes les demandes qui commencent par /calendar.

Vous pouvez filtrer les correspondances de caractères génériques par extension de fichier. Par exemple, si vous souhaitez ajouter une règle qui correspond uniquement aux fichiers HTML dans un chemin donné, vous pouvez créer la règle suivante :

{
  "route": "/articles/*.html",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

Pour filtrer sur plusieurs extensions de fichier, vous devez inclure les options entre accolades, comme illustré dans cet exemple :

{
  "route": "/images/thumbnails/*.{png,jpg,gif}",
  "headers": {
    "Cache-Control": "public, max-age=604800, immutable"
  }
}

Les cas d’usage courants pour les itinéraires de caractères génériques sont les suivants :

Servir un fichier spécifique pour un modèle de chemin complet
Appliquer des règles d’authentification et d’autorisation
Implémentation des règles de mise en cache spécialisées

Sécuriser les routes avec des rôles

Les itinéraires sont sécurisés en y ajoutant un ou plusieurs noms de rôles dans le tableau allowedRoles de la règle. Pour obtenir des exemples d’utilisation, consultez l’exemple de fichier config.

Important

Les règles d’acheminement peuvent uniquement sécuriser les requêtes HTTP vers les routes desservies à partir de Static Web Apps. De nombreuses infrastructures frontales utilisent le routage côté client qui modifie les routes dans le navigateur sans émettre de demandes pour Static Web Apps. Les règles d’acheminement ne sécurisent pas les routes côté client. Les clients doivent appeler des API HTTP pour récupérer des données sensibles. Veillez à ce que les API valident l’identité d’un utilisateur avant de renvoyer les données.

Par défaut, chaque utilisateur appartient au rôle anonymous intégré et tous les utilisateurs connectés sont membres du rôle authenticated. Si vous le souhaitez, les utilisateurs sont associés à des rôles personnalisés via des invitations.

Par exemple, pour limiter un itinéraire aux seuls utilisateurs authentifiés, ajoutez le rôle authenticated intégré au groupe allowedRoles.

{
  "route": "/profile*",
  "allowedRoles": ["authenticated"]
}

Vous pouvez créer des rôles en fonction des besoins dans le tableau allowedRoles. Pour restreindre un itinéraire aux seuls administrateurs, vous pouvez définir votre propre rôle, nommé administrator, dans le tableau allowedRoles.

{
  "route": "/admin*",
  "allowedRoles": ["administrator"]
}

Vous avez un contrôle total sur les noms de rôles ; il n’existe pas de liste à laquelle vos rôles doivent adhérer.
Les utilisateurs individuels sont associés à des rôles par le biais des invitations.

Important

Lors de la sécurisation du contenu, spécifiez les fichiers exacts si possible. Si vous avez de nombreux fichiers à sécuriser, utilisez des caractères génériques après un préfixe partagé. Par exemple : /profile* sécurise tous les itinéraires possibles qui commencent par /profile, y compris /profile.

Restriction de l’accès à l’ensemble de l’application

Vous devrez souvent exiger une authentification pour chaque itinéraire de votre application. Pour verrouiller vos itinéraires, ajoutez une règle qui correspond à tous les itinéraires et incluez le rôle intégré authenticated dans le tableau allowedRoles.

L’exemple de configuration suivant bloque l’accès anonyme et redirige tous les utilisateurs non authentifiés vers la page de connexion Microsoft Entra.

{
  "routes": [
    {
      "route": "/*",
      "allowedRoles": ["authenticated"]
    }
  ],
  "responseOverrides": {
    "401": {
      "statusCode": 302,
      "redirect": "/.auth/login/aad"
    }
  }
}

Remarque

Par défaut, tous les fournisseurs d’identité préconfigurés sont activés. Pour bloquer un fournisseur d’authentification, consultez Authentification et autorisation.

Itinéraires de secours

Les applications monopages s’appuient souvent sur le routage côté client. Ces règles d’acheminement côté client mettent à jour l’emplacement de la fenêtre du navigateur sans effectuer de demande au serveur. Si vous actualisez la page ou si vous accédez directement aux URL générées par les règles d’acheminement côté client, un itinéraire de secours côté serveur est requis pour servir la page HTML appropriée. La page de secours est souvent désignée comme étant index.html pour votre application côté client.

Vous pouvez définir une règle de secours en ajoutant une section navigationFallback. L’exemple suivant renvoie /index.html pour toutes les demandes de fichier statique qui ne correspondent pas à un fichier déployé.

{
  "navigationFallback": {
    "rewrite": "/index.html"
  }
}

Vous pouvez contrôler les demandes qui renvoient le fichier de secours en définissant un filtre. Dans l’exemple suivant, les demandes concernant certains itinéraires du dossier /images et tous les fichiers du dossier /css sont exclues du renvoi du fichier de secours.

{
  "navigationFallback": {
    "rewrite": "/index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  }
}

Par exemple, selon la structure de répertoire suivante, la règle de secours de navigation ci-dessus entraînerait les résultats détaillés dans le tableau suivant.

├── images
│   ├── logo.png
│   ├── headshot.jpg
│   └── screenshot.gif
│
├── css
│   └── global.css
│
└── index.html

Demande...	renvoie…	avec l’état…
/about/	Le fichier /index.html.	`200`
/images/logo.png	Le fichier image.	`200`
/images/icon.svg	Le fichier /index.html, étant donné que l’extension de fichier svg n’est pas répertoriée dans le filtre `/images/*.{png,jpg,gif}`.	`200`
/images/unknown.png	Erreur Fichier introuvable.	`404`
/css/unknown.css	Erreur Fichier introuvable.	`404`
/css/global.css	Le fichier de feuille de style.	`200`
Tout autre fichier en dehors des dossiers /images ou /css	Le fichier /index.html.	`200`

Important

Si vous effectuez une migration à partir du fichier routes.json déconseillé, n’incluez pas l’itinéraire de secours hérité ("route": "/*") dans les règles d’acheminement.

En-têtes globaux

La section globalHeaders fournit un ensemble d’en-têtes HTTP appliqués à chaque réponse, sauf s’ils sont remplacés par une règle d’en-tête d’itinéraire. Sinon, l’union des en-têtes de l’itinéraire et des en-têtes globaux est renvoyée.

Pour obtenir des exemples d’utilisation, consultez l’exemple de fichier config.

Pour supprimer un en-tête, définissez la valeur sur une chaîne vide ("").

Voici quelques cas d’usage courants pour les en-têtes globaux :

Règles de mise en cache personnalisées
Stratégies de sécurité
Paramètres de codage
Configuration du partage des ressources cross-origin (CORS)

L’exemple suivant implémente une configuration CORS personnalisée.

{
  "globalHeaders": {
    "Access-Control-Allow-Origin": "https://example.com",
    "Access-Control-Allow-Methods": "POST, GET, OPTIONS"
  }
}

Remarque

Les en-têtes globaux n’affectent pas les réponses d’API. Les en-têtes des réponses d’API sont conservés et retournés au client.

Remplacement des réponses

La section responseOverrides permet de définir une réponse personnalisée lorsque le serveur retourne un code d’erreur. Pour obtenir des exemples d’utilisation, consultez l’exemple de fichier config.

Les codes HTTP suivants peuvent être remplacés :

Code de statut	Signification	Cause possible
400	Demande incorrecte	Lien d’invitation non valide.
401	Non autorisé	Demande de pages à accès restreint sans authentification.
403	Interdit	L’utilisateur est connecté, mais ne dispose pas des rôles nécessaires pour afficher la page. L’utilisateur est connecté, mais le runtime ne peut pas récupérer les détails de l’utilisateur à partir de ses revendications d’identité. Un nombre trop élevé d’utilisateurs sont connectés au site via des rôles personnalisés. Le runtime ne peut donc pas connecter l’utilisateur.
404	Introuvable	Fichier introuvable

L’exemple de configuration suivant montre comment remplacer un code d’erreur.

{
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "statusCode": 302,
      "redirect": "/login"
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/custom-404.html"
    }
  }
}

Plateforme

La section platform contrôle les paramètres propres à la plateforme, comme la version du runtime de langage d’API.

Sélection de la version du runtime de langage d’API

Pour configurer la version du runtime de langage d’API, définissez la propriété apiRuntime de la section platform sur l’une des valeurs prises en charge suivantes.

Version du runtime de langage	Système d’exploitation	Version d’Azure Functions	Valeur `apiRuntime`	Date de fin de prise en charge
.NET Core 3.1	Windows	3.x	`dotnet:3.1`	3 décembre 2022
.NET 6.0 in-process	Windows	4.x	`dotnet:6.0`	-
.NET 6.0 isolé	Windows	4.x	`dotnet-isolated:6.0`	-
.NET 7.0 isolé	Windows	4.x	`dotnet-isolated:7.0`	-
.NET 8.0 isolé	Windows	4.x	`dotnet-isolated:8.0`	-
Node.js 12.x	Linux	3.x	`node:12`	3 décembre 2022
Node.js 14.x	Linux	4.x	`node:14`	-
Node.js 16.x	Linux	4.x	`node:16`	-
Node.js 18.x	Linux	4.x	`node:18`	-
Python 3.8	Linux	4.x	`python:3.8`	-
Python 3.9	Linux	4.x	`python:3.9`	-
Python 3.10	Linux	4.x	`python:3.10`	-

.NET

Pour changer la version du runtime dans une application .NET, changez la valeur TargetFramework dans le fichier csproj. Bien que facultative, si vous définissez une valeur apiRuntime dans le fichier staticwebapp.config.json, vérifiez que la valeur correspond à ce que vous définissez dans le fichier csproj.

L’exemple suivant montre comment mettre à jour l’élément TargetFramework pour NET 8.0 comme version du runtime de langage d’API dans le fichier csproj.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    ...
  </PropertyGroup>
...

Node.js

L’exemple de configuration suivant montre comment utiliser la propriété apiRuntime pour sélectionner Node.js 16 comme version du runtime de langage d’API dans le fichier staticwebapp.config.json.

{
  ...
  "platform": {
    "apiRuntime": "node:16"
  }
  ...
}

Python

L’exemple de configuration suivant montre comment utiliser la propriété apiRuntime pour sélectionner Python 3.8 comme version du runtime de langage d’API dans le fichier staticwebapp.config.json.

{
  ...
  "platform": {
    "apiRuntime": "python:3.8"
  }
  ...
}

Mise en réseau

La section networking contrôle la configuration réseau de votre application web statique. Pour restreindre l’accès à votre application, spécifiez une liste de blocs d’adresses IP autorisés dans allowedIpRanges. Pour plus d’informations sur le nombre de blocs d’adresses IP autorisés, consultez Quotas dans Azure Static Web Apps.

Remarque

La configuration de la mise en réseau est uniquement disponible dans le plan Standard d’Azure Static Web Apps.

Définissez chaque bloc d’adresses IPv4 dans la notation CIDR (Classless InterDomain Routing). Pour plus d’informations sur la notation de routage CIDR, consultez Routage CIDR (Classless InterDomain Routing). Chaque bloc d’adresses IPv4 peut désigner un espace d’adressage public ou privé. Si vous souhaitez autoriser l’accès à partir d’une seule adresse IP, vous pouvez utiliser le bloc CIDR /32.

{
  "networking": {
    "allowedIpRanges": [
      "10.0.0.0/24",
      "100.0.0.0/32",
      "192.168.100.0/22"
    ]
  }
}

Lorsqu’un ou plusieurs blocs d’adresses IP sont spécifiés, les demandes provenant d’adresses IP qui ne correspondent à aucune valeur dans allowedIpRanges se voient refuser l’accès.

En plus des blocs d’adresses IP, vous pouvez également spécifier des étiquettes de service dans le tableau allowedIpRanges pour limiter le trafic vers certains services Azure.

"networking": {
  "allowedIpRanges": ["AzureFrontDoor.Backend"]
}

Authentification

Les fournisseurs d’authentification par défaut ne nécessitent pas de paramètres dans le fichier de configuration.
Les fournisseurs d’authentification personnalisés utilisent la section auth du fichier de paramètres.

Pour plus d’informations sur la façon de restreindre les routes vers les utilisateurs authentifiés, consultez Sécurisation des routes avec des rôles.

Désactiver le cache pour les chemins authentifiés

Si vous avez activé l’intégration manuelle avec Azure Front Door, vous pouvez désactiver la mise en cache pour vos routes sécurisées. Une fois la périphérie de niveau entreprise activée, la mise en cache est déjà désactivée pour vos itinéraires sécurisés.

Pour désactiver la mise en cache Azure Front Door pour les routes sécurisées, ajoutez "Cache-Control": "no-store" à la définition d’en-tête de routage.

Par exemple :

{
    "route": "/members",
    "allowedRoles": ["authenticated, members"],
    "headers": {
        "Cache-Control": "no-store"
    }
}

Passerelle de transfert

La section forwardingGateway configure le mode d’accès à une application web statique à partir d’une passerelle de transfert, telle qu’un Réseau de distribution de contenu (CDN) ou une Azure Front Door.

Remarque

La configuration de la passerelle de transfert est uniquement disponible dans le plan Standard d’Azure Static Web Apps.

Hôtes transférés autorisés

La liste allowedForwardedHosts spécifie les noms d’hôte à accepter dans l’en-tête X-Forwarded-Host. Si un domaine correspondant figure dans la liste, Static Web Apps utilise la valeur X-Forwarded-Host lors de la construction des URL de redirection, par exemple, après une connexion réussie.

Pour que Static Web Apps fonctionne correctement derrière une passerelle de transfert, la demande de la passerelle doit inclure le nom d’hôte correct dans l'en-tête X-Forwarded-Host et le même nom d’hôte doit être indiqué dans allowedForwardedHosts.

"forwardingGateway": {
  "allowedForwardedHosts": [
    "example.org",
    "www.example.org",
    "staging.example.org"
  ]
}

Si l'en-tête X-Forwarded-Host ne correspond pas à une valeur de la liste, les demandes sont toujours exécutées, mais l’en-tête n’est pas utilisé dans la réponse.

En-têtes obligatoires

Les en-têtes requis sont des en-têtes HTTP qui doivent être envoyés avec chaque demande adressée à votre site. Une utilisation des en-têtes requis consiste à refuser l’accès à un site, sauf si tous les en-têtes requis sont présents dans chaque demande.

Par exemple, la configuration suivante montre comment vous pouvez ajouter un identificateur unique pour Azure Front Door qui limite l’accès à votre site à partir d’une instance Azure Front Door. Pour plus d’informations, consultez le didacticiel Configurer Azure Front Door .

"forwardingGateway": {
  "requiredHeaders": {
    "X-Azure-FDID" : "692a448c-2b5d-4e4d-9fcc-2bc4a6e2335f"
  }
}

Les paires clé/valeur peuvent être n’importe quel ensemble de chaînes arbitraires
Les clés sont insensibles à la casse
Les valeurs respectent la casse

Barre oblique de fin

Une barre oblique de fin est / à la fin d’une URL. Traditionnellement, l’URL de barre oblique de fin fait référence à un répertoire sur le serveur web, tandis qu’une barre oblique non finale indique un fichier.

Les moteurs de recherche traitent les deux URL séparément, qu’il s’agisse d’un fichier ou d’un répertoire. Lorsque le même contenu est affiché pour ces deux URL, votre site Web traite du contenu dupliqué, ce qui peut avoir un impact négatif sur l’optimisation du référencement d’un site auprès d’un moteur de recherche (SEO). Lorsqu’elle est configurée explicitement, Static Web Apps applique un ensemble de règles de normalisation et de redirection d’URL qui permettent d’améliorer les performances et le référencement de votre site web.

Les règles de normalisation et de redirection suivantes s’appliquent à chacune des configurations disponibles :

Toujours

Lorsque vous définissez la valeur always pour trailingSlash, toutes les demandes qui n’incluent pas de barre oblique de fin sont redirigées vers une URL de barre oblique de fin. Par exemple, /contact est redirigé vers /contact/.

"trailingSlash": "always"

Demande...	renvoie…	avec l’état…	et le chemin...
/about	Le fichier /about/index.html	`301`	/about/
/about/	Le fichier /about/index.html	`200`	/about/
/about/index.html	Le fichier /about/index.html	`301`	/about/
/contact	Le fichier /contact.html	`301`	/contact/
/contact/	Le fichier /contact.html	`200`	/contact/
/contact.html	Le fichier /contact.html	`301`	/contact/

Jamais

Lorsque vous définissez la valeur never pour trailingSlash, toutes les requêtes terminant par une barre oblique de fin sont redirigées vers une URL sans barre oblique de fin. Par exemple, /contact/ est redirigé vers /contact.

"trailingSlash": "never"

Demande...	renvoie…	avec l’état…	et le chemin...
/about	Le fichier /about/index.html	`200`	/about
/about/	Le fichier /about/index.html	`301`	/about
/about/index.html	Le fichier /about/index.html	`301`	/about
/contact	Le fichier /contact.html	`200`	/contact
/contact/	Le fichier /contact.html	`301`	/contact
/contact.html	Le fichier /contact.html	`301`	/contact

Automatique

Lorsque vous définissez la valeur auto pour trailingSlash, toutes les demandes adressées aux dossiers sont redirigées vers une URL avec une barre oblique de fin. Toutes les requêtes adressées aux fichiers sont redirigées vers une URL sans barre oblique de fin.

"trailingSlash": "auto"

Demande...	renvoie…	avec l’état…	et le chemin...
/about	Le fichier /about/index.html	`301`	/about/
/about/	Le fichier /about/index.html	`200`	/about/
/about/index.html	Le fichier /about/index.html	`301`	/about/
/contact	Le fichier /contact.html	`200`	/contact
/contact/	Le fichier /contact.html	`301`	/contact
/contact.html	Le fichier /contact.html	`301`	/contact

Pour optimiser les performances du site web, configurez une stratégie de barre oblique de fin à l’aide de l’un des modes always, never ou auto.

Par défaut, lorsque la configuration trailingSlash est omise, Static Web Apps applique les règles suivantes :

Demande...	renvoie…	avec l’état…	et le chemin...
/about	Le fichier /about/index.html	`200`	/about
/about/	Le fichier /about/index.html	`200`	/about/
/about/index.html	Le fichier /about/index.html	`200`	/about/index.html
/contact	Le fichier /contact.html	`200`	/contact
/contact/	Le fichier /contact.html	`301`	/contact
/contact.html	Le fichier /contact.html	`200`	/contact.html

Exemple de fichier de configuration

{
  "trailingSlash": "auto",
  "routes": [
    {
      "route": "/profile*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/admin/index.html",
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/images/*",
      "headers": {
        "cache-control": "must-revalidate, max-age=15770000"
      }
    },
    {
      "route": "/api/*",
      "methods": ["GET"],
      "allowedRoles": ["registeredusers"]
    },
    {
      "route": "/api/*",
      "methods": ["PUT", "POST", "PATCH", "DELETE"],
      "allowedRoles": ["administrator"]
    },
    {
      "route": "/api/*",
      "allowedRoles": ["authenticated"]
    },
    {
      "route": "/customers/contoso*",
      "allowedRoles": ["administrator", "customers_contoso"]
    },
    {
      "route": "/login",
      "rewrite": "/.auth/login/github"
    },
    {
      "route": "/.auth/login/twitter",
      "statusCode": 404
    },
    {
      "route": "/logout",
      "redirect": "/.auth/logout"
    },
    {
      "route": "/calendar*",
      "rewrite": "/calendar.html"
    },
    {
      "route": "/specials",
      "redirect": "/deals",
      "statusCode": 301
    }
  ],
  "navigationFallback": {
    "rewrite": "index.html",
    "exclude": ["/images/*.{png,jpg,gif}", "/css/*"]
  },
  "responseOverrides": {
    "400": {
      "rewrite": "/invalid-invitation-error.html"
    },
    "401": {
      "redirect": "/login",
      "statusCode": 302
    },
    "403": {
      "rewrite": "/custom-forbidden-page.html"
    },
    "404": {
      "rewrite": "/404.html"
    }
  },
  "globalHeaders": {
    "content-security-policy": "default-src https: 'unsafe-eval' 'unsafe-inline'; object-src 'none'"
  },
  "mimeTypes": {
    ".json": "text/json"
  }
}

En fonction de la configuration ci-dessus, passez en revue les scénarios suivants.

Demande...	a pour résultat…
/profile	Les utilisateurs authentifiés reçoivent le fichier /profile/index.html. Les utilisateurs non authentifiés sont redirigés vers /login par la règle de remplacement de réponse `401`.
/admin, /admin/ ou /admin/index.html	Les utilisateurs authentifiés ayant le rôle administrator reçoivent le fichier /admin/index.html. Les utilisateurs authentifiés qui n’ont pas le rôle administrator reçoivent une erreur `403`¹. Les utilisateurs non authentifiés sont redirigés vers /login
/images/logo.png	Délivre l’image avec une règle de cache personnalisée dont l’âge maximal est un peu plus de 182 jours (15 770 000 secondes).
/api/admin	Les demandes `GET` des utilisateurs authentifiés ayant le rôle registeredusers sont envoyées à l’API. Les utilisateurs authentifiés qui n’ont pas le rôle registeredusers et les utilisateurs non authentifiés reçoivent une erreur `401`. Les demandes `POST`, `PUT`, `PATCH` et `DELETE` des utilisateurs authentifiés ayant le rôle administrator sont envoyées à l’API. Les utilisateurs authentifiés qui n’ont pas le rôle administrator et les utilisateurs non authentifiés reçoivent une erreur `401`.
/customers/contoso	Les utilisateurs authentifiés qui appartiennent aux rôles administrator ou customers_contoso reçoivent le fichier /customers/contoso/index.html. Les utilisateurs authentifiés qui n’ont pas le rôle administrator ou customers_contoso reçoivent une erreur `403` ¹. Les utilisateurs non authentifiés sont redirigés vers /login.
/login	Les utilisateurs non authentifiés sont invités à s’authentifier auprès de GitHub.
/.auth/login/twitter	Comme l’autorisation avec Twitter est désactivée par la règle d’acheminement, une erreur `404` est renvoyée, ce qui revient à remettre /index.html avec un code d’état `200`.
/logout	Les utilisateurs sont déconnectés de tous les fournisseurs d’authentification.
/calendar/2021/01	Le navigateur reçoit le fichier /calendar.html.
/specials	Le navigateur est redirigé de façon permanente vers /deals.
/data.json	Le fichier remis avec le type MIME `text/json`.
/about, ou tout dossier qui correspond aux modèles de routage côté client	Le fichier /index.html est remis avec un code d’état `200`.
Un fichier inexistant dans le dossier /images/	Une erreur `404`.

¹ Vous pouvez fournir une page d’erreur personnalisée en utilisant une règle de remplacement de la réponse.

Restrictions

Les restrictions suivantes existent pour le fichier staticwebapp.config.json.

La taille maximale des fichiers est de 20 Ko
Maximum de 50 rôles distincts.

Consultez l’article sur les quotas pour connaître les restrictions et les limitations générales.

Étapes suivantes

Configurer l’authentification et l’autorisation

Configurer Azure Static Web Apps

Emplacement du fichier

Itinéraires

Définir des itinéraires

Spécification de modèles d’itinéraire

Itinéraire exact

Modèle de caractère générique

Sécuriser les routes avec des rôles

Restriction de l’accès à l’ensemble de l’application

Itinéraires de secours

En-têtes globaux

Remplacement des réponses

Plateforme

Sélection de la version du runtime de langage d’API

.NET

Node.js

Python

Mise en réseau

Authentification

Désactiver le cache pour les chemins authentifiés

Passerelle de transfert

Hôtes transférés autorisés

En-têtes obligatoires

Barre oblique de fin

Toujours

Jamais

Automatique

Exemple de fichier de configuration

Restrictions

Étapes suivantes

Articles connexes

Ressources supplémentaires