2017-07-04 3 views
1

Dies ist die letzte Folge (hoffe ich) der langen Geschichte namensAzurblau. URL neu schreiben Authentifizierungsmodus Formulare.

Zurück Folgen „Wie ich in der Regel iis verwandte Themen behandeln“: Ep1. Ep2.

So.

Ich habe URL-Rewrite eingerichtet, um alle Hauptwebseiten-API-Anfragen mit dem Reverse-Proxy zu behandeln und sie an die neue API hinter der Szene zu übergeben.

Alles funktioniert gut außer dem Fall, wenn die API (die neue Web-App) Status 401 zurückgibt (wegen des falschen Tokens usw.).

Der Benutzer sollte die 401 nicht autorisierte sehen, aber es versucht, ihn stattdessen an die "/login?returnUrl=some/api/url/which/returns/401/status" umleiten.

Wie ich verstehe, geschah es aufgrund der Tatsache, dass ich solche Authentifizierung Setup in web.config der Hauptwebsite habe.

<authentication mode="Forms"> 
     <forms loginUrl="~/login" timeout="100000" requireSSL="false" /> 
</authentication> 

So ist die Anfrage-Workflow sieht wie folgt aus:

  1. Benutzer fordert mainapp.com/api/some/endpoint.
  2. IIS behandelt sie mit URL Rewrite und Umleitungen an die apiapp.com/api/some/endpoint
  3. apiapp.com es Griffe und gibt Status-401
  4. mainapp.com 401 Status Griffe und gibt 302 Status mit /login?returnUrl=api/some/endpoint

Warum die p .4 ist passiert? Ich muss nur die Antwort weitergeben und mainapp.com nicht daran denken.

Ist es möglich, es irgendwie zu lösen?

+0

apiapp.com Was Sie erwarten ist ein Reverse-Proxy-Verhalten von mainapp.com. Ich habe Ihren EP1 überprüft, daher nehme ich an, dass Sie Reverse Proxy konfiguriert haben. Dies widerspricht jedoch Ihrem Punkt 2, wie Sie hier erwähnt haben, dass die Anfrage umgeleitet wird. Es wird hilfreich sein, wenn Sie angeben, wo die Websites in Azure gehostet werden, und die URL-Rewrite-Abschnitte für beide Websites. Ohne diese ist es sehr schwierig, etwas zu sagen. Möglicherweise möchten Sie auch die Verfolgung fehlgeschlagener Anfragen für die Webanwendung aktivieren, um dies weiter zu untersuchen. –

+0

URL Nur für die MainApp neu schreiben. Ja beide auf azurblau. Keine Umleitung, nur umschreiben. – korovaisdead

+0

Also, wenn Sie Azure sagen, ist es Azure App Service oder VM oder Cloud-Service? –

Antwort

0

So nach Ihrem Setup ist dies der Anforderungsablauf:

Client ----> mainapp.com ----> apiapp.com

nach Ihren Angaben Mainapp.com ist als Reverse Proxy eingerichtet. Punkt 4 schlägt jedoch etwas anderes vor. Um sicher zu sein, können Sie aktivieren Failed Request Tracing auf den Web-Anwendungen und überprüfen Sie die Protokolle.

Dies ist ein 2-Stufen-Prozess,

  1. aktivieren Anforderungsfehler im Portal

    enter image description here

  2. Fügen Sie den folgenden Abschnitt zur Bahnverfolgung.Konfiguration Ihrer Web-App (Root-):

Dies wird Ihnen helfen zu verstehen, was auf die Anfrage passiert ist.

+0

Ich verstehe ziemlich genau, was das Problem verursacht. Dies ist der Authentifizierungsabschnitt in der web.config der Hauptwebsite. Aber ich werde versuchen, fehlgeschlagene Anfragen zu überprüfen. – korovaisdead

+0

Sie haben also den Abschnitt "" in mainapp.com? Wenn ja, dann empfehle ich Ihnen, das gesamte Setup zu überprüfen. –

+0

Ja, ich habe ... Ich habe das in der Hauptfrage geschrieben, übrigens. Das einzige, was ich erreichen möchte, ist, alle Anfragen an die mainapp.com/api/* mit apiapp.com/api/* zu bearbeiten und das wars. – korovaisdead

0

Ich habe genau das gleiche Problem. In meinem Fall war der Übeltäter in der web.config von mainapp.com. Insbesondere wurde die Authentifizierung nach Bedarf festgelegt, und ich hatte eine Weiterleitung zu login.aspx definiert. Der Code säumige war hier:

<authentication mode="Forms"> 
     <forms name="yourAuthCookie" loginUrl="login.aspx" protection="All" path="/" /> 
</authentication> 
<authorization> 
     <allow users="?" /> 
</authorization> 

Danach Kommentierung aus, ich konnte beweisen, dass es die mainapp.com war, dass die 401 nicht autorisiert von der Proxy-Aufruf zurückgibt wurde