… oder wie Fiddler mir geholfen hat eine fehlerhafte Reverse-Proxy Konfiguration bei der Veröffentlichung eines internen SharePoint-Portals zu umgehen.
Die Story
Einer unserer Kunden betreibt eine lokale Installation von SharePoint für sein Intranet. Im Laufe des Projekts wurde klar, dass auch von extern von Mitarbeitern auf den SharePoint zugegriffen werden sollte. Nun war SharePoint aber bereits mit portal.acme.local intern veröffentlicht. Für den externen Zugriff sollte aber eine Adresse wie portal.acme-extranet.de verwendet werden.
Für die IT-Abteilung des Kunden war es kein Problem, eine Web-Anwendung von extern unter einem anderen Namen zu veröffentlichen. Dazu stellt die IT einen Reverse Proxy zur Verfügung, der die eingehenden Anfragen an das interne Portal weiterleitet.
Das Problem
Nun hat die IT also den Reverse Proxy eingerichtet und alle Anfragen von https://portal.acme-extranet.de werden an http://portal.acme.local umgeleitet. Nun ist auf der Empfängerseite ein SharePoint, der die Anfrage für bare Münze nimmt. Als Folge werden interne Links und URLs in dem von SharePoint generierten HTML auch auf http://portal.acme.local gemünzt. In der Antwort für den Client sind die Links dann aber falsch, weil unter dieser Adresse die sind Ressourcen von extern ja nicht zu erreichen, da es sich dabei ja um eine interne Adresse handelt.
Glücklicherweise ist nur an wenigen Stellen in den URLs auch der Hostname inklusive Protokoll enthalten. Viele Links sind relativ zum Host, so dass diese funktionieren, egal wie die Seiten aufgerufen werden. Aber es gibt dennoch einige Stellen, an denen der Hostname aus der Anfrage eingefügt werden. Gerade im JavaScript findet sich der Hostname mehrfach wieder. Somit funktionieren diese Funktionen in diesem Fall nicht.
Das Problem an dieser Stelle ist, dass der Reverse-Proxy die Anfrage intern an http://portal.acme.local umleitet und nicht den original Host-Headernamen https://portal.acme-extranet.de im HTTP-Request beibehält (nur damit funktioniert dann das AAM im SharePoint auch richtig).
Die Lösung
Solange die die Konfiguration des Reverse-Proxy nicht angepasst wird kann man von extern nicht vollständig auf SharePoint zugreifen … oder … ich verwende Fiddler.
Wenn ich zunächst in meinem Browser http://portal.acme.local aufrufe, dann bekomme ich eine Fehlermeldung, dass der Name nicht aufgelöst werden kann.
Nun habe ich also mal meinen Fiddler gestartet und der Traffic meines Browsers geht durch Fiddler. Und nun kommt Magic … ich kann im Fiddler mit Fiddler-Script in die Verarbeitung eingreifen, indem ich Custom-Rules definiere. So gibt es ein OnBeforeRequest-Event in dem ich in die Verarbeitung eines Requests in Fiddler eingreifen kann. Hier habe ich nun folgenden Eingriff vorgenommen:
if (oSession.HostnameIs("portal.acme.local")) {
oSession.hostname="portal.acme-extranet.de";
oSession.fullUrl = "https" + oSession.fullUrl.Substring(oSession.fullUrl.IndexOf(':'));
}
Damit erreiche ich, dass aller Traffic, den mein Browser an http://portal.acme.local sendet an https://portal.acme-extranet.de umgelenkt wird. Somit ist mir egal wie die URLs in der HTML-Antwort von SharePoint aussehen und ich somit auch auf Seite und Funktionen zugreifen kann, die mir vorher verwehrt waren, weil sie nur die “interne” URL angezeigt haben.
Das Ziel
Als Ergebnis kann ich nun auch mit ShareGate auf das Portal zugreifen und dort Daten migrieren, was vorher nicht möglich war, weil insbesondere in den Antworten der Webservices immer die komplette URL angegeben ist, und alle Antworten auf einen Webservice-Aufruf immer gegen die interne Adresse laufen.
