it-swarm.com.de

http zu https umschreiben zu viele Weiterleitungsschleifen IIS 7

Ich habe eine Anwendung, die ich in IIS 7.0 gehostet habe ..... Dort muss ich sicherstellen, dass es nur auf HTTPS und nicht auf HTTP funktioniert. Ich habe die folgende Regel in meine Root-Konfiguration eingefügt.

<rewrite>
        <rules>
            <rule name="HTTP to HTTPS redirect" stopProcessing="true">
              <match url="(.*)" />
              <conditions>
                <add input="{HTTPS}" pattern="off" />
              </conditions>
              <action type="Redirect" url="https://{HTTP_Host}{REQUEST_URI}"   redirectType="Found" />
            </rule>
        </rules>
</rewrite> 

Nachdem ich diese Regel hinzugefügt habe, als ich versuchte, auf meine Anwendung zuzugreifen, erhalte ich folgende Fehlermeldung:

Die Seite hat zu viele Weiterleitungen ergeben. Löschen Sie Ihre Cookies für Diese Website oder das Zulassen von Cookies von Drittanbietern kann das Problem beheben. Wenn nicht, Es handelt sich möglicherweise um ein Problem mit der Serverkonfiguration und nicht um ein Problem mit dein Computer. Hier einige Vorschläge: Diese Webseite später erneut laden. Erfahren Sie mehr über dieses Problem.

12
Prashant Mohite

Stellen Sie die Eingabebedingung unter:

<add input="{HTTPS}" pattern="on" /> 

Anstatt:

<add input="{HTTPS}" pattern="off" />
17
Gparmar

Wir haben unsere ASP.NET-Anwendung auf AWS mit Elastic Load Balancing gehostet, und die Regel in der Frage mit der akzeptierten Antwort funktionierte nicht für uns und verursachte unendliche Weiterleitungen.

Dies ist die Regel, die schließlich für uns funktioniert hat:

<rewrite>
   <rules>
      <rule name="HTTPS Rule behind AWS Elastic Load Balancer Rule" stopProcessing="true">
         <match url="^(.*)$" ignoreCase="false" />
         <conditions>
            <add input="{HTTP_X_FORWARDED_PROTO}" pattern="^http$" ignoreCase="false" />
         </conditions>
         <action type="Redirect" url="https://{SERVER_NAME}{URL}" redirectType="Found" />
      </rule>
   </rules>
</rewrite>
6
SNag

Mein Fall musste ich so formulieren:

<rewrite>
<rules>
    <rule name="HTTP to HTTPS redirect" stopProcessing="true">
      <match url="(.*)" ignoreCase="false" />
      <conditions logicalGrouping="MatchAny">
        <add input="{HTTP_X_FORWARDED_PROTO}" pattern="^http$" />
        <add input="{HTTPS}" pattern="on" />
      </conditions>
      <action type="Redirect" url="https://{HTTP_Host}{REQUEST_URI}"   redirectType="Found" />
    </rule>
</rules>

3
Junior Grão

Für IIS 10 (Windows Server 2016) habe ich die Anweisungen von here befolgt, die eine etwas andere XML-Konfiguration für das Umschreiben erzeugen:

<rewrite>
    <rules>
        <rule name="HTTP 2 HTTPS" patternSyntax="Wildcard" stopProcessing="true">
            <match url="*" />
            <conditions logicalGrouping="MatchAny">
                <add input="{HTTPS}" pattern="off" />
            </conditions>
            <action type="Redirect" url="https://{HTTP_Host}{REQUEST_URI}" redirectType="Found" />
        </rule>
    </rules>
</rewrite>

Das Muster ist off und die Übereinstimmung ist nur *

1
Alexei

Ich verwende Liquid Web Cloud Sites und habe genau dasselbe Problem festgestellt.

Ich habe die Lösung hier ausprobiert, aber sie hat aufgrund dieser Bedingung nicht funktioniert:

<add input="{HTTPS}" pattern="off" />

Wie das OP es hat, bedeutet dies "Übereinstimmung und Implementierung dieser Regel, wenn HTTPS ausgeschaltet ist" . Und die akzeptierte Lösung für diese Frage kehrt dies nur um und entspricht der Regel, wenn HTTPS aktiviert ist . Das Problem mit der Endlosschleife wurde behoben, aber nur, weil meine Regel nicht richtig übereinstimmte. Ich möchte die Anforderung eigentlich nur in HTTPS ändern, wenn HTTPS deaktiviert ist. Daher wurde keine meiner HTTP-Anfragen weitergeleitet.

Interessanterweise wurde auch keine meiner HTTPS-Anforderungen weitergeleitet, und aus diesem (und einigen anderen Tests, die ich durchgeführt habe) ergab sich, dass der Browser zwar HTTPS anzeigt, der Server dies jedoch wie eine HTTP-Anforderung behandelt. Daher glaubt der Server immer, eine HTTP-Anfrage zu erhalten, und ignoriert immer die Regel (die jetzt nur Übereinstimmungsanfragen angibt, bei denen HTTPS aktiviert ist - d. H. Nie).

Stundenlanges Forschen und Testen später folgerte ich, dass es sich um ein ähnliches Problem handelt wie hier beschrieben , hier zusammengefasst:

Um die Kosten zu senken [viele Hosting-Anbieter installieren das] SSL-Zertifikat auf dem TMG-Gateway, und dieses Gateway schreibt die Anforderung einfach auf Standard-HTTP um, wenn es an den eigentlichen Webserver weitergeleitet wird. Wenn die Anforderung IIS und Ihre Webanwendung erreicht, handelt es sich also um eine normale HTTP-Anforderung.

.

TLDR;

Irgendwann sprach ich mit dem Team von Liquid Web, das mich auf einen Hilfeartikel hinwies, der auf seiner eigenen Website vergraben war und das Problem löste. Sie schlugen vor, ich verwende die folgende Umschreiberegel, die das Problem behebt:

<system.webServer>
 <rewrite>
  <rules>
   <rule name="Redirect to HTTPS" stopProcessing="true">
     <match url=".*"/>
    <conditions>
     <add input="{HTTP_CLUSTER_HTTPS}" pattern="^on$" negate="true"/>
     <add input="{HTTP_CLUSTER_HTTPS}" pattern=".+" negate="true"/>
    </conditions>
    <action type="Redirect" url="https://{HTTP_Host}{SCRIPT_NAME}" redirectType="SeeOther"/>
   </rule>
  </rules>
 </rewrite>
</system.webServer>

Ich hoffe, dass dies für andere in einer ähnlichen Situation funktionieren könnte.

Original liquidweb Hilfeartikel

0
DoubleA

Wie von SNag erwähnt, hatten wir eine Website, die hinter einer ELB bei Amazon sitzt. Der Versuch, eine Umschreibungsregel ohne den folgenden Eingabeheader anzuwenden, führte zu unendlichen Weiterleitungen. Dies scheint darauf zurückzuführen zu sein, dass der Eingabetyp HTTP_X_FORWARDED_PROTO wie folgt ist: <add input="{HTTP_X_FORWARDED_PROTO}" pattern="^http$" ignoreCase="false" />

Aus der AWS-Dokumentation "Ihre Anwendung oder Website kann das im X-Forwarded-Proto-Anforderungsheader gespeicherte Protokoll verwenden, um eine Antwort zu liefern, die auf die entsprechende URL umleitet." Wir verwenden die ELB mit DNS-Einträgen, um an den Server mit der Site darauf weiterzuleiten. 

0
nshouppuohsn