Partager via

Scénarios et configurations du moteur de règles Azure Front Door

Le moteur de règles Azure Front Door permet aux utilisateurs de personnaliser facilement la logique de traitement et de routage sur le bord Front Door en configurant des paires de conditions et d’actions de correspondance.

Vous pouvez définir différentes actions de règle en fonction de la combinaison de 19 conditions de correspondance prises en charge à partir de requêtes entrantes. Ces règles vous permettent de :

  1. Gérer dynamiquement la stratégie de cache

  2. Transférer des demandes vers différentes origines ou versions

  3. Modifiez les en-têtes de demande ou de réponse pour masquer les informations sensibles ou transmettre des informations importantes via des en-têtes. Par exemple, l’implémentation d’en-têtes de sécurité pour empêcher les vulnérabilités basées sur un navigateur, telles que :

    • HTTP strict-transport-security (HSTS)
    • Protection X-XSS
    • Stratégie de sécurité du contenu
    • Options X-frame
    • Access-Control-Allow-Origin en-têtes pour les scénarios de partage de ressources inter-origines (CORS). Les attributs basés sur la sécurité peuvent également être définis avec des cookies.

  4. Réécrire les chemins d’URL ou rediriger les demandes vers de nouvelles destinations

  5. Activez des scénarios complexes à l’aide de variables regex et de serveur : capturez des valeurs dynamiques à partir de requêtes ou de réponses entrantes, puis combinez-les avec des chaînes statiques ou d’autres variables.

Cet article traite des cas d’usage courants pris en charge par le moteur de règles Azure Front Door et fournit des exemples de configuration détaillés pour répondre à diverses exigences métier et techniques.

Scénario 1 : Rediriger à l’aide de chaîne de requête, de segments de chemin d’URL ou de captures de nom d’hôte entrants

La gestion des redirections est essentielle pour l’optimisation du moteur de recherche (SEO), l’expérience utilisateur et le bon fonctionnement d’un site web. Le moteur de règles et les variables serveur d’Azure Front Door vous permettent de gérer efficacement les redirections par lots en fonction de différents paramètres.

  • Redirigez en fonction des paramètres de chaîne de requête : Vous pouvez rediriger des requêtes à l’aide de champs de requête de l’URL entrante en capturant la valeur d’une clé de chaîne de requête spécifique au format {http_req_arg_<key>}.

    Par exemple, extrayez la valeur de la clé de cdpb requête à partir d’une URL entrante : https://example.mydomain.com/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount et utilisez-la pour configurer l’hôte de destination en URL sortante : https://teststorageaccount.blob.core.windows.net/testcontainer/123.zip?sig=fffff&cdpb=teststorageaccount.

    Cette approche permet des redirections dynamiques sans avoir à créer une règle distincte pour chaque cdpb valeur, réduisant considérablement le nombre de règles requises.

    Capture d’écran montrant comment utiliser la chaîne de requête pour rediriger l’URL.

  • Rediriger en fonction des segments de chemin d’URL de longueur fixe : Vous pouvez rediriger les demandes vers différentes origines en fonction du segment de chemin d’URL de longueur fixe en capturant les segments d’URL à l’aide {variable:offset:length}de . Pour plus d’informations, consultez le format de variable serveur.

    Par exemple, considérez un scénario dans lequel l’ID de locataire est incorporé dans le segment d’URL et est toujours de six caractères longs, tels que : https://api.contoso.com/{tenantId}/xyz. Pour extraire {tenantId} de l’URL et décider de la redirection appropriée à utiliser au format .tenantId.backend.com/xyz

    Cette approche élimine la nécessité de créer une règle distincte pour chaque ID de locataire, ce qui vous permet de gérer le routage dynamique avec moins de règles.

    Capture d’écran montrant comment utiliser le segment de chemin de longueur fixe pour rediriger l’URL.

  • Redirigez en fonction des segments de chemin d’URL de longueur dynamique : Lorsque le segment de chemin d’accès d’URL a une longueur dynamique, vous pouvez l’extraire à l’aide du {url_path:seg#}. Pour plus d’informations, consultez le format de variable serveur.

    Par exemple, si un ID de locataire ou un emplacement est incorporé dans le segment d’URL, tel que : https://api.contoso.com/{tenantId}/xyz, vous pouvez extraire {tenantId} de l’URL et décider de la redirection correcte au format tenantId.backend.com/xyz en utilisant la variable de serveur {url_path:seg0}.backend.com dans l'hôte de destination de la redirection.

    Cette méthode évite de créer des règles distinctes pour chaque ID de locataire, ce qui permet une configuration plus efficace.

    N/A

  • Redirigez en fonction d’une partie du nom d’hôte entrant : Vous pouvez rediriger les demandes vers différentes origines en extrayant une partie du nom d’hôte entrant.

    Par exemple, vous pouvez capturer tenantName à partir de https://[tenantName].poc.contoso.com/GB pour rediriger la requête vers s1.example.com/Buyer/Main?realm=[tenantName]&examplename=example1, en utilisant le décalage et la longueur dans la variable serveur au format de {hostname:0:-16}. Pour plus d’informations, consultez le format de variable serveur.

    Capture d’écran montrant comment utiliser le nom d’hôte entrant pour rediriger l’URL.

Scénario 2 : Remplir ou modifier un en-tête de réponse en fonction d’une valeur d’en-tête de requête

Dans certains scénarios, vous devrez peut-être remplir ou modifier un en-tête de réponse en fonction d’une valeur d’en-tête de requête.

Par exemple, vous pouvez ajouter un en-tête CORS si nécessaire pour traiter des scripts sur plusieurs origines du même domaine CDN, et la réponse doit contenir le même nom de domaine complet dans l’en-tête Access-Control-Allow-Origin que l’en-tête d’origine de la requête, plutôt qu’un caractère générique permettant à tous les domaines (*) d’améliorer la sécurité. Vous pouvez l’atteindre à l’aide de la {http_req_header_Origin} variable de serveur pour définir l’en-tête de réponse.

Capture d’écran montrant comment modifier un en-tête de réponse en fonction d’une valeur d’en-tête de requête.

Scénario 3 : Renommer un en-tête de réponse en un en-tête spécifique à la marque

Vous pouvez renommer un en-tête de réponse généré par un fournisseur de cloud en ajoutant un nouvel en-tête de réponse personnalisé et en supprimant l’original.

Par exemple, vous pouvez remplacer l’en-tête X-Azure-Backend-ID de réponse par un en-tête X-Contoso-Scale-IDspécifique à la marque.

Capture d’écran montrant comment renommer un en-tête de réponse en un en-tête spécifique à une marque.

Scénario 4 : Test A/B (expérimentation)

Le fractionnement du trafic entrant en deux groupes d’origine peut être utile dans les tests A/B, les déploiements propagés ou l’équilibrage de charge sans logique principale complexe.

Par exemple, vous pouvez fractionner le trafic entrant en fonction du numéro de port client. Une règle peut correspondre aux ports clients qui se terminent par 1, 3, 5, 7 ou 9 et transfèrent ces demandes à un groupe d’expériences-origines. Tous les autres trafics continuent vers le groupe d’origine par défaut par paramètres d’itinéraire. Le regex précédent n’est qu’un exemple. Vous pouvez explorer et tester vos propres expressions à l’aide d’outils tels que regex101.

Remarque

Étant donné que les ports clients sont aléatoires, cette méthode entraîne généralement un fractionnement approximatif de 50/50 du trafic. Toutefois, la présence de proxys ou d’équilibreurs de charge entre les clients et Front Door peut affecter cette hypothèse en raison de facteurs tels que la réutilisation de la connexion ou la réécriture de port source. Utilisez des logs ou des métriques pour valider le comportement réel de votre environnement.

Capture d’écran montrant comment fractionner le trafic entrant en deux groupes d’origine.

Scénario 5 : Rediriger avec la modification du chemin d’URL et conserver la fonctionnalité

Dans certains scénarios, vous devrez peut-être ajouter de nouveaux segments ou supprimer certains segments tout en conservant le reste du chemin d’URL.

Par exemple, si vous souhaitez rediriger https://domain.com/seg0/seg1/seg2/seg3 vers https://example.com/seg0/insert/seg2/seg3. Dans ce scénario, vous remplacez le chemin d’URL {seg1}/insert/ par celui-ci tout en conservant le reste du chemin d’URL. Azure Front Door effectue la redirection souhaitée en combinant les valeurs extraites des variables serveur (segments d'URL) avec le segment de texte statique /insert/. Vous pouvez utiliser Int32.Max (2147483647) pour le champ de longueur du segment d’URL afin de conserver tous les segments de seg2 à segn. Pour plus d’informations, consultez le format de variable serveur.

Remarque

Une configuration similaire peut être effectuée pour l’action de réécriture d’URL en plaçant le modèle source en tant que / destination comme /{url_path:seg0}/insert/{url_path:seg2:2147483647} pour l’action de redirection, comme indiqué dans l’exemple de portail suivant.

Capture d’écran montrant comment rediriger avec la modification du chemin d’accès d’URL tout en conservant une partie du chemin d’URL.

Scénario 6 : Rediriger en supprimant des parties fixes d’un chemin d’URL

Vous pouvez supprimer des segments fixes de taille connue d’un chemin d’URL, tels que les codes de pays (nous) ou les paramètres régionaux (en-us), tout en conservant le reste du chemin d’URL.

Par exemple, si vous souhaitez rediriger https://domain.com/us/seg1/seg2/seg3/ vers https://example.com/seg1/seg2/seg3/, vous devez supprimer le code /us/ du pays et conserver le reste du chemin d’URL inchangé.

Pour ce faire, utilisez {variable:offset} , qui inclut la variable de serveur après un décalage spécifique, jusqu’à la fin de la variable. Pour plus d’informations, consultez le format de variable serveur.

Remarque

Une configuration similaire peut être effectuée pour l’action de réécriture d’URL en plaçant le modèle source en tant que / destination comme /“{url_path:3} pour l’action de redirection, comme indiqué dans l’exemple de portail suivant.

Capture d’écran montrant comment rediriger en supprimant des parties fixes d’un chemin d’URL.

Scénario 7 : Réécriture d’URL en supprimant un ou plusieurs segments de chemin d’URL

Vous pouvez supprimer un ou plusieurs segments d’un chemin d’URL, tels que les codes de pays (nous) ou les paramètres régionaux (en-us), tout en conservant le reste du chemin d’URL.

Par exemple, si vous souhaitez réécrire https://domain.com/us/seg1/seg2/seg3/https://origin.com/seg2/seg3/, vous devez supprimer à la fois le code de pays et un segment /us/seg1/ supplémentaire tout en conservant le reste du chemin d’URL intact.

Pour ce faire, utilisez le {url_path:seg#:length} format de variable serveur pour capturer des segments d’URL spécifiques à partir d’un numéro de segment particulier. Dans cet exemple, utilisez cette option {url_path:seg2:2147483647} pour capturer tous les segments commençant de seg2 à la fin. La valeur 2147483647 (Int32.Max) garantit que tous les segments restants sont inclus. Pour plus d’informations, consultez le format de variable serveur.

Capture d’écran montrant comment utiliser la réécriture d’URL pour supprimer un ou plusieurs segments de chemin d’URL.

Remarque

Lorsque vous utilisez des variables de serveur comme {url_path} dans le champ De destination , le paramètre Conserver le chemin d’accès sans correspondance devient moins pertinent, car les variables serveur vous donnent un contrôle explicite sur les parties du chemin d’URL à inclure.

Scénario 8 : Utiliser des expressions régulières pour réduire le nombre de conditions de règle et éviter d’atteindre des limites

L’utilisation de regex dans les conditions de règle peut réduire considérablement le nombre de règles requises, ce qui permet d’éviter les limites de règles qui peuvent être un bloqueur pour les clients qui ont besoin de conditions ou d’actions pour des centaines de clients.

Par exemple, si un client souhaite identifier ses clients avec un modèle d’ID spécifique pour autoriser l’accès à une ressource derrière Azure Front Door, les clients envoient un en-tête comme x-client-id: SN1234-ABCD56. Cet en-tête suit un format spécifique : x-client-id: <SN + 4 digits + - + 4 uppercase letters + 2 digits>.

Au lieu de créer des règles individuelles pour chaque ID client possible, vous pouvez utiliser un modèle d’expression ^SN[0-9]{4}-[A-Z]{4}[0-9]{2}$ régulière unique pour faire correspondre tous les ID client valides dans une règle, par exemple, SN1234-ABCD56, , SN0001-ZYXW99SN2025-QWER12, SN9876-MNOP34, , SN3141-TEST42, etc. Cette approche vous permet de gérer des centaines d’ID client différents avec une configuration de règle unique.

Capture d’écran montrant comment utiliser regex pour faire correspondre les modèles d’ID client.

Remarque

Vous pouvez utiliser regex101 pour tester et valider vos modèles regex avant de les implémenter dans Azure Front Door.

Scénario 9 : Modifier les redirections d’origine à l’aide des captures d’en-tête de réponse

Vous pouvez rendre dynamiques les champs d’action à l’aide de valeurs d’en-tête de réponse en tant que variables de serveur. Cela est utile lorsque les serveurs d’origine émettent des redirections qui référencent leurs propres noms de domaine.

Le problème : Les serveurs d’origine tels qu’Azure App Service émettent généralement des URL de redirection qui référencent leur propre nom de domaine (par exemple). contoso.azurewebsites.net Si ces URL atteignent le client non modifié, la requête suivante contourne Azure Front Door, ce qui interrompt l’expérience de navigation de l’utilisateur.

La solution : Capturez l’en-tête de l’origine Location et réécrire uniquement la partie hôte afin qu’elle reflète toujours le nom d’hôte utilisé par le client à l’origine.

Par exemple, si l’en-tête d’hôte du client frontend vers Azure Front Door est contoso.com et que l’origine est contoso.azurewebsites.net, lorsque l’origine émet une URL de redirection absolue comme Location : https://contoso.azurewebsites.net/login/, vous pouvez modifier l'en-tête de localisation pour réutiliser le nom d’hôte d’origine : Location : https://contoso.com/login/

Pour ce faire, utilisez le format variable du serveur : https://{hostname}{http_resp_header_location:33}, où :

  • {hostname} représente le nom d’hôte du client d’origine (contoso.com)
  • {http_resp_header_location:33} capture le contenu de l’en-tête Location à partir de l'offset 33 (la partie /login/)

Pour plus d’informations, consultez Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end.

Capture d’écran montrant comment modifier les redirections d’origine à l’aide de captures d’en-têtes de réponse.

Remarque

  • Cette règle peut être utilisée lorsque la condition de règle est basée sur des paramètres de requête ou lorsqu’elle est appelée inconditionnellement.

  • Pour le calcul de décalage cohérent, tous les serveurs d’origine du groupe d’origine doivent avoir des noms de domaine de la même longueur, par exemple, tous les 33 caractères comme https://contoso.azurewebsites.net. Dans l’idéal, il ne doit y avoir qu’un seul serveur d’origine, mais plusieurs origines sont acceptables si leurs noms ont des longueurs identiques.

  • Vous pouvez appliquer la même technique de capture de variable serveur pour extraire et réutiliser les paramètres de chaîne de requête dans différentes actions de règle.

Scénario 10 : règles If-elseif-else

Le moteur de règles Azure Front Door ne prend pas en charge en mode natif la logique conditionnelle traditionnelle avec des structures « if-elseif-else ». Par défaut, toutes les règles sont évaluées indépendamment comme « if condition1, action1 », « if condition2, action2 », etc. Lorsque plusieurs conditions sont remplies simultanément, plusieurs actions correspondantes sont exécutées.

Toutefois, vous pouvez émuler la logique « if-elseif-else-else » à l’aide de la fonctionnalité Arrêter d’évaluer les règles restantes pour créer une branche conditionnelle semblable à ceci :

  • Si condition1 est satisfaite, exécutez action1 et arrêtez
  • Sinon, si condition2 est satisfaite (mais condition1 n’est pas), exécutez action2 et arrêtez
  • Sinon, si condition3 est satisfaite (mais condition1 et condition2 ne sont pas), exécutez action3 et arrêtez
  • Sinon, exécutez une action par défaut

Fonctionnement : Lorsque plusieurs conditions sont normalement satisfaites simultanément, seule la première règle correspondante s’exécute, car l’évaluation des règles s’arrête après la première correspondance. Cela simule efficacement la branche conditionnelle traditionnelle.

Étapes de configuration :

  1. Créez un ensemble de règles (par exemple, « IfElseifElseRuleset »)
  2. Créer des règles dans l’ordre de priorité, avec les conditions les plus spécifiques d’abord
  3. Pour chaque règle, vérifiez l’option Arrêter l’évaluation des règles restantes

Capture d’écran montrant comment configurer des règles if-elseif-else.

Important

Le paradigme if-elseif-else fonctionne uniquement si l’ensemble de règles est attaché comme jeu de règles final pour cette route.

Capture d’écran montrant comment placer des règles if-elseif-else comme ensemble de règles finals pour l’itinéraire.

Scénario 11 : Supprimer les chaînes de requête des URL entrantes à l’aide de redirections d’URL

Vous pouvez supprimer les chaînes de requête des URL entrantes en implémentant une redirection d’URL 3xx qui guide les utilisateurs vers le point de terminaison Azure Front Door, sans les chaînes de requête.

Remarque

Les utilisateurs remarqueront la modification de l’URL de la requête avec cette opération.

L’exemple suivant montre comment supprimer l’intégralité de la chaîne de requête des URL entrantes. Si vous devez enlever une partie, vous pouvez ajuster le décalage/la longueur comme vous le souhaitez. Pour plus d’informations, consultez le format de variable serveur.

Capture d’écran montrant comment supprimer des chaînes de requête des URL entrantes à l’aide des redirections URL 3xx.

Scénario 12 : Ajouter un jeton SAS dans la chaîne de requête pour authentifier Azure Front Door sur Stockage Azure

Vous pouvez protéger les fichiers de votre compte de stockage en modifiant l’accès à vos conteneurs de stockage de public en privé et en utilisant des signatures d’accès partagé (SAP) pour accorder des droits d’accès restreints à vos ressources stockage Azure à partir d’Azure Front Door sans exposer votre clé de compte. Vous pouvez également effectuer cette opération à l’aide de l’identité managée. Pour plus d’informations, consultez Utiliser des identités managées pour s’authentifier à des origines.

Fonctionnement de l’injection de jeton SAS : Capturez le chemin d’URL entrant et ajoutez le jeton SAP à la chaîne de requête à l’aide de règles de redirection ou de réécriture. Étant donné que la réécriture d’URL agit uniquement sur le chemin d’accès, utilisez des règles de redirection lorsque vous devez modifier des chaînes de requête.

Par exemple, si vous souhaitez ajouter un jeton SAS à l’URL entrante : https://www.contoso.com/dccp/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399, l’URL de réécriture sera : https://www.contoso.com/grammars/0.1.0-59/en-US/grammars/IVR/ssn0100_CollectTIN_QA_dtmf.grxml?version=1.0_1719342835399&<SASTOKEN>

Dans cet exemple, l’URL entrante a déjà des paramètres de requête et vous souhaitez conserver la chaîne de requête existante lors de l’ajout du jeton SAP en configurant la redirection d’URL à l’aide /{url_path:seg1:20}?{query_string}&<SASToken>de .

La configuration de la règle redirige toutes les requêtes HTTPS qui ne contiennent pas encore le jeton SAS (identifié par l’absence de sp=rl dans la chaîne de requête).

Capture d’écran montrant comment ajouter un jeton SAP dans la chaîne de requête.

Important

  • Mettez à jour votre configuration des routes pour vous assurer que les routes pour /grammars/* sont correctement configurées après la redirection.

  • Remplacez le jeton SAP par le jeton approprié. Dans l’exemple, le jeton SAP commence par sp=rl, et vous souhaitez rediriger toutes les requêtes pour appliquer cette règle qui ne contient pas le sp=rl

Scénario 13 : Ajouter des en-têtes de sécurité avec le moteur de règles

Vous pouvez utiliser le moteur de règles Azure Front Door pour ajouter des en-têtes de sécurité qui aident à empêcher les vulnérabilités basées sur un navigateur, telles que HTTP Strict-Transport-Security (HSTS), X-XSS-Protection, Content-Security-Policy et X-Frame-Options.

Par exemple, vous pouvez ajouter un en-tête Content-Security-Policy à toutes les requêtes entrantes qui correspondent au chemin défini dans l’itinéraire associé à la configuration du moteur de règles. Dans cette configuration, utilisez script-src 'self' https://apiphany.portal.azure-api.net la valeur d’en-tête pour autoriser uniquement les scripts du site https://apiphany.portal.azure-api.net approuvé à s’exécuter sur l’application. Pour plus d’informations, consultez Ajouter des en-têtes de sécurité avec le moteur de règles.

Capture d’écran montrant comment ajouter des en-têtes de sécurité avec le moteur de règles.

Contenu connexe