Freigeben über


Erweiterte Extranetunterstützung

Letzte Änderung: Freitag, 30. April 2010

Gilt für: SharePoint Foundation 2010

Microsoft SharePoint Foundation stellt für Fälle, in denen ein a Reverseproxyserver zwischen dem Clientcomputer und dem Webserver mit SharePoint Foundation implementiert werden muss, ein Objektmodell für das Erstellen und Verwalten von ein- und ausgehenden URLs bereit. Eine eingehende URL ist die URL einer Anforderung, die den Webserver mit SharePoint Foundation erreicht. SharePoint Foundation ermittelt diese URL anhand des Protokolls der Anwendungsebene (HTTP oder HTTPS), des Hostheaders im HTTP-Paket und des Zielports des TCP-Pakets. Eine ausgehende URL ist die absolute Basis-URL, die von SharePoint Foundation in den Links verwendet wird, die auf den an den Benutzer zurückgegebenen Seiten generiert werden.

Eine Reverseproxykonfiguration kann beispielsweise dann erforderlich sein, wenn ein und dieselbe SharePoint-Website sowohl intern innerhalb eines Unternehmens oder einer Organisation als auch extern für ein Extranet oder das Internet veröffentlicht werden muss. In diesem Fall verwenden zwei Server denselben Inhalt gemeinsam, und der Reverseproxy wird nur für den extern veröffentlichten Server eingesetzt. Der intern veröffentlichte Server ist direkt über HTTP zugänglich, während der nach außen gerichtete Server nur über eine SSL-Anforderung (Secure Sockets Layer) an den Reverseproxyserver erreichbar ist.

Bei der erweiterten Extranetunterstützung kommen die folgenden Reverseproxykonfigurationen zum Einsatz:

  • SSL-Beendigung: Der Benutzer gibt beim Zugriff auf eine SharePoint-Website https als Protokoll in der URL an. Ein Reverseproxyserver empfängt die SSL-Anforderung, konvertiert sie in eine HTTP-Anforderung (http) und leitet diese an den Server mit SharePoint Foundation weiter.

  • Hostheaderänderung: Eine Anwendung, die eine Webanforderung generiert, schließt in die Anforderung einen so genannten Hostheader ein. Der HTTP-Hostheader gibt den Host an, der vom Benutzer in die URL eingegeben wurde. In dieser Konfiguration erfolgt der Zugriff auf eine SharePoint-Website mithilfe einer URL wie http://www.example.com, wobei www.example.com der Host ist. Ein Reverseproxyserver empfängt die Anforderung, ändert den Hostheader in den internen Namen des Servers mit SharePoint Foundation (z. B. sharepoint.internal.example.com) und leitet die Anforderung dann an diesen Server weiter.

  • Portkonvertierung: Der Benutzerzugriff auf eine SharePoint-Website erfolgt unter Verwendung einer bestimmten Portnummer, beispielsweise 80 für HTTP-Anforderungen. Ein Reverseproxyserver empfängt die Anforderung und leitet sie an den Server mit SharePoint Foundation auf einem anderen Port weiter (z. B. 1234).

In all diesen Fällen wird die ursprüngliche Anforderungs-URL vom Reverseproxyserver verändert, sodass eine andere URL entsteht. Bevor es die erweiterte Extranetunterstützung gab, ging SharePoint Foundation davon aus, dass die empfangene eingehende URL der ursprünglichen Anforderungs-URL entsprach. Die eingehende URL wurde daher in den Links, die auf den an den Benutzer zurückgegebenen Seiten generiert wurden, als absolute URL verwendet, sodass der Benutzer eine falsche URL erhielt. Die erweiterte Extranetunterstützung ermöglicht in SharePoint Foundation nun die Verwendung eines anderen Protokolls, Hostnamens und einer anderen Portnummer in den Links, die auf den an den Benutzer zurückgegebenen Seiten generiert werden.

Ein Reverseproxyserver empfängt eine Anforderung für eine bestimmte URL vom Clientcomputer. Der Proxyserver ordnet die Anforderung daraufhin einer anderen URL für den Webserver mit SharePoint Foundation zu. Beispielsweise könnte der Proxyserver eine Anforderung wie https://www.example.com/sites/Site/default.aspx empfangen, diese aber als http://nn.nn.nnn.nn/sites/Site/default.aspx an den Webserver weiterleiten. Dank der erweiterten Extranetunterstützung kann SharePoint Foundation so angepasst werden, dass in allen Links auf den Seiten die ursprüngliche Basis-URL (z. B. https://www.example.com) unverändert zurückgegeben wird.

HinweisHinweis

Die erweiterte Extranetunterstützung betrifft nur Inhaltswebanwendungen und gilt nicht für die SharePoint-Website oder -Webanwendung für die Zentraladministration.

SharePoint Foundation untersucht die vom Proxyserver erhaltenen Pakete und isoliert das Protokoll, den Hostnamen und die Portnummer der Anforderung oder eingehenden URL. Anschließend wird anhand zweier Tabellen die korrekte Basis der zurückzugebenden URL ermittelt: In einer Tabelle wird jede eingehende URL einer bestimmten Zone zugeordnet, in der zweiten Tabelle wird jede Zone einer bestimmten ausgehenden URL zugeordnet. SharePoint Foundation formuliert die URLs auf den Seiten unter Verwendung der ausgehenden Basis-URL um, die anhand der Tabellen ermittelt wird.

Zonen bilden eingehende URLs, die in SharePoint Foundation vom Proxyserver empfangen werden, auf ausgehenden URLs ab, die in den Links verwendet werden, die auf den an den Benutzer zurückgegebenen Seiten generiert werden. Fünf Zonen pro virtuellem Server stehen für die verschiedenen Zugriffsmöglichkeiten für eine SharePoint-Website: Intranet, Internet, Extranet, Benutzerdefiniert und Standard. Jede Zone kann zwar beliebig viele eingehende URLs aufweisen, aber nur eine einzige ausgehende URL.

Die folgenden Typen des Microsoft.SharePoint.Administration-Namespace stellen Möglichkeiten zum Erstellen und Verwalten von alternativen Anforderungs-URLs auf einem virtuellen Server bereit:

Die AlternateServerUrlFromHttpRequestUrl-Methode der SPUtility-Klasse gibt die ausgehende URL zurück, die einer bestimmten eingehenden URL zugeordnet ist.

In SharePoint Foundation können Sie verwaltete Pfade für die ausdrückliche Inklusion oder die Platzhalterinklusion definieren. Administrative Richtlinien für das Definieren von verwalteten Pfaden und zur Verwendung von Reverseproxyservern finden Sie unter Planen von alternativen Zugriffszuordnungen (Office SharePoint Server).