Résoudre les problèmes d’App Service dans Application Gateway

Découvrez comment diagnostiquer et résoudre les problèmes que vous pouvez rencontrer quand Azure App Service est utilisé comme cible de back-end avec Azure Application Gateway.

Vue d’ensemble

Dans cet article, vous allez apprendre à résoudre les problèmes suivants, comme décrit de façon plus détaillée dans le Centre des architectures : Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end

• URL absolues incorrectes
• URLs de redirection incorrectes
  • L’URL du service d’application est exposée dans le navigateur en cas de redirection
  • Exemple : un flux d’authentification OIDC est rompu en raison d’une redirection avec un nom d’hôte incorrect ; cela implique l’utilisation de l’authentification et de l’autorisation App Service
• Cookies rompus
  • Les cookies ne sont pas propagés entre le navigateur et le service d’application
  • Exemple : le domaine de cookie ARRAffinity du service d’application est défini sur le nom d’hôte du service d’application et est lié à « exemple.azurewebsites.net », et non à l’hôte d’origine. De ce fait, l’affinité de session est rompue.

La cause racine des symptômes décrits ci-dessus est une configuration qui remplace le nom d’hôte utilisé entre Application Gateway et App Service par un nom d’hôte différent, tel que le navigateur le voit. Souvent, le nom d’hôte est remplacé par le domaine par défaut « azurewebsites.net » d’App Service.

Exemple de configuration

Si votre configuration correspond à l’une des deux cas décrits ci-dessous, votre installation est concernée par les instructions contenues dans cet article :

• Choisir un nom d’hôte à partir d’une adresse back-end est activé dans les paramètres HTTP
• Remplacement par un nom de domaine spécifique est défini sur une valeur différente de celle indiquée dans la requête du navigateur

Cause

App Service étant un service multilocataire, il utilise l’en-tête d’hôte de la requête pour router celle-ci vers le point de terminaison approprié. Le nom de domaine par défaut des App Services, *.azurewebsites.net (par exemple, contoso.azurewebsites.net), est différent du nom de domaine de la passerelle d’application (par exemple, contoso.com). Il manque dans le service d’application back-end le contexte nécessaire à la génération d’URL de redirection ou des cookies qui correspondent au domaine tel que le voit le navigateur.

Solution

La solution recommandée pour la production consiste à configurer Application Gateway et App Service de sorte qu’ils ne remplacent pas le nom d’hôte. Suivez les instructions pour « Domaine personnalisé (recommandé) » dans Configurer App Service avec Application Gateway.

Si vous envisagez d’appliquer une autre solution de contournement (comme la réécriture de l’en-tête Location comme décrit ci-dessous), ne le faites pas avant d’avoir pris connaissance des implications décrites dans l’article : Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end. Ces implications incluent la possibilité que les cookies liés au domaine et les URL absolues situées à l’extérieur de l’en-tête Location restent rompus.

Solution de contournement : réécrire l’en-tête Location

Avertissement

Cette configuration présente des limitations. Nous vous recommandons de prendre connaissance des implications d’une utilisation de noms d’hôte différents entre le client et Application Gateway et entre l’application et App Service au niveau du back-end. Pour plus d’informations, consultez l’article dans le Centre des architectures : Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end

Définissez le nom d’hôte de l’en-tête d’emplacement sur le nom de domaine de la passerelle d’application. Pour ce faire, créez une règle de réécriture avec une condition qui détermine si l’en-tête d’emplacement de la réponse contient azurewebsites.net. Elle doit aussi exécuter une action de façon à réécrire l’en-tête d’emplacement et lui attribuer le nom d’hôte de la passerelle d’application. Pour plus d’informations, voir les instructions de réécriture de l’en-tête d’emplacement.

Remarque

La prise en charge de la réécriture d’en-tête HTTP n’est disponible que pour les références (SKU) Standard_v2 et WAF_v2 d’Application Gateway. Nous vous recommandons de migrer vers v2 pour la réécriture d’en-tête et d’autres fonctionnalités avancées disponibles avec la référence SKU v2.

Étapes suivantes

Si les étapes précédentes ne vous permettent pas de résoudre le problème, ouvrez un ticket de support.