Behandeln von App Service-Problemen in Application Gateway

Erfahren Sie, wie Sie Probleme diagnostizieren und beheben, die ggf. auftreten, wenn Azure App Service als Back-End-Ziel mit Azure Application Gateway verwendet wird.

Überblick

In diesem Artikel erfahren Sie, wie Sie die folgenden Probleme beheben, wie im Architecture Center unter Beibehalten des ursprünglichen HTTP-Hostnamens zwischen einem Reverseproxy und seiner Back-End-Webanwendung ausführlicher beschrieben wird.

• Falsche absolute URLs
• Falsche Umleitungs-URLs
  • Die App-Dienst-URL wird im Browser verfügbar gemacht, wenn eine Umleitung durchgeführt wird.
  • Beispiel: Ein OIDC-Authentifizierungsfluss wird aufgrund einer Umleitung mit falschem Hostnamen unterbrochen. Dies schließt die Verwendung der App Service-Authentifizierung und -Autorisierung ein.
• Fehlerhafte Cookies
  • Cookies werden nicht zwischen dem Browser und App Service weitergereicht.
  • Beispiel: Die ARRAffinity-Cookiedomäne des App-Diensts ist auf den App-Dienst-Hostnamen „example.azurewebsites.net“ festgelegt und an diesen gebunden, und nicht auf den ursprünglichen Host. Infolgedessen ist die Sitzungsaffinität unterbrochen.

Die Grundursache für die oben genannten Symptome ist ein Setup, das den von Application Gateway verwendeten Hostnamen überschreibt und für App Service durch einen anderen als den im Browser angezeigten Hostnamen ersetzt. Häufig wird der Hostname in die App Service-Standarddomäne „azurewebsites.net“ überschrieben.

Beispielkonfiguration

Falls Ihre Konfiguration einer der folgenden beiden Situationen entspricht, gelten für Ihr Setup die Anweisungen in diesem Artikel:

• Hostnamen aus Back-End-Adresse auswählen ist aktiviert.
• Mit einem bestimmten Domänennamen überschreiben ist auf einen anderen Wert als den der Browseranforderung festgelegt.

Ursache

Da App Service ein mehrinstanzenfähiger Dienst ist, nutzt er den Hostheader in der Anforderung zur Weiterleitung der Anforderung an den richtigen Endpunkt. Der Standarddomänenname von App Service („*.azurewebsites.net“, z. B. „contoso.azurewebsites.net“) unterscheidet sich vom Domänennamen des Anwendungsgateways (z. B. „contoso.com“). App Service im Back-End fehlt der erforderliche Kontext zum Generieren von Umleitungs-URLs oder Cookies, die der im Browser angezeigten Domäne entsprechen.

Lösung

Die für die Produktion empfohlene Lösung besteht darin, Application Gateway und App Service so zu konfigurieren, dass der Hostname nicht überschrieben wird. Befolgen Sie die Anweisungen für Benutzerdefinierte Domäne (empfohlen) unter Konfigurieren von App Service mit Application Gateway.

Erwägen Sie nur, eine weitere Problemumgehung anzuwenden (z. B. eine Umschreibung des Location-Headers wie unten beschrieben), nachdem Sie die Auswirkungen geprüft haben, wie im folgenden Artikel beschrieben wird: Beibehalten des ursprünglichen HTTP-Hostnamens zwischen einem Reverseproxy und seiner Back-End-Webanwendung. Denn zu den möglichen Auswirkungen gehört, dass domänengebundene Cookies und absolute URLs außerhalb des Location-Headers weiterhin fehlerhaft sein könnten.

Problemumgehung: Umschreiben des Location-Headers

Warnung

Diese Konfiguration ist mit Einschränkungen versehen. Es wird empfohlen, die Auswirkungen der Verwendung verschiedener Hostnamen zwischen Client und Application Gateway sowie zwischen Anwendung und App Service im Back-End zu überprüfen. Weitere Informationen finden Sie im Artikel im Architecture Center: Beibehalten des ursprünglichen HTTP-Hostnamens zwischen einem Reverseproxy und seiner Back-End-Webanwendung.

Legen Sie den Hostnamen im Adressheader auf den Domänennamen des Anwendungsgateways fest. Erstellen Sie hierzu eine Regel zum erneuten Generieren mit einer Bedingung, die prüft, ob der Adressheader in der Antwort „azurewebsites.net“ enthält. Außerdem muss eine Aktion zum erneuten Generieren des Adressheaders durchgeführt werden, damit der Hostname des Anwendungsgateways vorhanden ist. Weitere Informationen finden Sie in der Anleitung unter Ändern einer Umleitungs-URL.

Hinweis

Die Unterstützung für das erneute Generieren von HTTP-Headern ist nur für die Standard_v2- und WAF_v2-SKU von Application Gateway verfügbar. Es wird empfohlen, für das erneute Schreiben von Headern und andere erweiterte Funktionen, die mit der v2-SKU verfügbar sind, zu v2 zu migrieren.

Nächste Schritte

Wenn sich das Problem mit den obigen Schritten nicht beheben lässt, sollten Sie ein Supportticket erstellen.