Partager via


Support extranet avancé

Dernière modification : vendredi 30 avril 2010

S’applique à : SharePoint Foundation 2010

Microsoft SharePoint Foundation fournit un modèle objet qui permet de créer et de gérer les URL entrantes et sortantes lorsqu'un serveur proxy inverse doit être implémenté entre l’ordinateur client et le serveur Web qui exécute SharePoint Foundation. Une URL entrante est l’URL d’une demande qui atteint le serveur Web exécutant SharePoint Foundation. SharePoint Foundation détermine cette URL en examinant le protocole de la couche application (HTTP ou HTTPS), l’en-tête de l’hôte dans le paquet HTTP et le port de destination du paquet TCP. Une URL sortante est l’URL de base absolue que SharePoint Foundation utilise dans les liens qu’il génère dans les pages retournées ensuite à l’utilisateur.

Une configuration de proxy inverse peut être nécessaire, par exemple, lorsque le même site SharePoint doit être tourné à la fois vers l’intérieur d’une entreprise ou d’une organisation, et vers l’extérieur (extranet ou Internet). Dans ce cas, deux serveurs partagent le même contenu, et le proxy inverse s’applique uniquement au serveur tourné vers l’extérieur. Le serveur tourné vers l’intérieur est directement accessible par HTTP, tandis que le serveur tourné vers l’extérieur peut être atteint uniquement par une requête SSL (Secure Sockets Layer) adressée au serveur proxy inverse.

Le support extranet avancé résout les configurations de proxy inverse suivantes :

  • Arrêt de SSL : l’utilisateur accède à un site SharePoint en spécifiant https en tant que protocole dans l’URL. Un serveur proxy inverse reçoit la demande SSL, la convertit en une demande HTTP (http) et transmet la demande convertie au serveur qui exécute SharePoint Foundation.

  • Modification d’en-tête d’hôte : une application qui génère une demande Web inclut un en-tête dans la demande appelé l’en-tête de l’hôte. L’en-tête de l’hôte HTTP identifie l’hôte que l’utilisateur a entré dans l’URL. Dans cette configuration, l’utilisateur accède à un site SharePoint à l’aide d’une URL telle que http://www.example.com, où l’hôte est www.example.com. Un serveur proxy inverse reçoit la demande, remplace l’en-tête de l’hôte par le nom interne du serveur qui exécute SharePoint Foundation, tel que sharepoint.internal.example.com, puis transmet la demande à ce serveur.

  • Conversion de port : l’utilisateur accède à un site SharePoint à l’aide d’un numéro de port particulier, tel que 80 pour les requêtes HTTP. Un serveur proxy inverse reçoit la demande et l’envoie au serveur qui exécute SharePoint Foundation sur un port différent, par exemple 1234.

Dans chacun de ces cas, le serveur proxy inverse modifie l’URL de la demande d’origine. Avant l'ajout du support extranet avancé, SharePoint Foundation supposait que l’URL entrante reçue était l’URL de la demande d’origine. Il utilisait cette URL entrante comme URL absolue dans les liens qu’il générait dans les pages retournées ensuite à l’utilisateur, alors que cette URL était incorrecte pour l’utilisateur. Le support extranet avancé permet à SharePoint Foundation d’utiliser un protocole, un nom d’hôte et un numéro de port différents dans les liens qu’il génère sur les pages retournées à l’utilisateur.

Un serveur proxy inverse reçoit une demande pour une URL spécifique à partir de l’ordinateur client ; le serveur proxy remappe ensuite la demande vers une URL différente pour le serveur Web qui exécute SharePoint Foundation. Par exemple, le serveur proxy peut recevoir une demande telle que https://www.example.com/sites/Site/default.aspx, mais transférer la demande au serveur Web en tant que http://nn.nn.nnn.nn/sites/Site/default.aspx. Grâce au support extranet avancé, SharePoint Foundation peut être personnalisé pour retourner la même base d’URL d’origine (par exemple, https://www.example.com) dans tous les liens sur ses pages.

Notes

Le support extranet avancé s’applique uniquement aux applications Web de contenu, et non au site Web Administration centrale SharePoint ou à l’application Web.

SharePoint Foundation examine les paquets qu’il reçoit du serveur proxy et isole le protocole, le nom d’hôte et le numéro de port indiqués dans l’URL entrante ou de la demande. Il utilise ensuite deux tables pour déterminer la base correcte de l’URL à renvoyer : une table mappe chaque URL entrante sur une zone particulière, tandis que l’autre table mappe chaque zone sur une URL sortante particulière. SharePoint Foundation réécrit les URL indiquées dans ses pages en utilisant l’URL de base sortante qu’il trouve dans les tables.

Les zones mappent les URL entrantes que SharePoint Foundation reçoit du serveur proxy sur les URL sortantes qu’il utilise dans les liens qu’il génère dans les pages retournées ensuite à l’utilisateur. Cinq zones par serveur virtuel représentent les différentes manières d’accéder à un site SharePoint : intranet, Internet, extranet, personnalisée et par défaut. Bien que chaque zone puisse comporter n’importe quel nombre d’URL entrantes, chaque zone ne peut détenir qu’une seule URL sortante.

Les types suivants de l’espace de noms Microsoft.SharePoint.Administration permettent de créer et de gérer des URL de demande de remplacement sur un serveur virtuel :

La méthode AlternateServerUrlFromHttpRequestUrl de la classe SPUtility retourne l’URL sortante qui est associée à une URL entrante spécifiée.

SharePoint Foundation vous permet de définir des chemins d’accès gérés pour une inclusion explicite ou une inclusion générique. Pour une aide administrative sur la définition de chemins d’accès gérés et sur l’utilisation de serveurs proxy inverse, voir Planifier les mappages des accès de substitution (Office SharePoint Server).