Microsoft SharePoint Foundation comme application ASP.NET
Dernière modification : vendredi 28 janvier 2011
S’applique à : SharePoint Foundation 2010
Dans cet article
Configuration ASP.NET et IIS
Le pipeline de demande
Pourquoi SharePoint modifie-t-il le pipeline ?
Comment SharePoint modifie-t-il le pipeline ?
Cette rubrique explique la construction de Microsoft SharePoint Foundation sur un ensemble de modifications du pipeline de demande intégré des services Internet (IIS) et de Microsoft ASP.NET.
Notes
Elle décrit le fonctionnement d’IIS et d’ASP.NET en mode intégré. Ils peuvent également fonctionner en mode classique, mais comme les applications Web SharePoint Foundation doivent appartenir à des pools d’applications utilisant le mode intégré, le mode classique n’est pas abordé dans cette rubrique.
Notes
Bien que cette rubrique fasse référence aux fichiers web.config et aux fichiers associés, elle ne traite pas de la personnalisation de ces fichiers. Pour des informations sur la personnalisation de la configuration de SharePoint Foundation, voir Utiliser des fichiers Web.config.
Configuration ASP.NET et IIS
Les paramètres de configuration d’IIS, d’ASP.NET, ainsi que des sites Web, des applications et des services construits sur ces derniers, sont stockés dans une hiérarchie de fichiers de configuration. Le principe général est que chaque fichier de la hiérarchie a une portée plus étroite que le fichier du niveau supérieur, et peut remplacer, sur sa portée, des paramètres des fichiers supérieurs dans la hiérarchie. Il est également possible de verrouiller certains paramètres dans l’un de ces fichiers de configuration pour empêcher que les fichiers inférieurs dans la hiérarchie ne remplacent ces paramètres.
Le sommet de la hiérarchie est constitué par le fichier machine.config, situé dans le répertoire %WinDir%\Microsoft.NET\Framework64\v2.0.50727\CONFIG\. Ce fichier contient les paramètres de serveur.
Le fichier web.config global, situé dans le même répertoire, est un second fichier de configuration de serveur.
Notes
SharePoint Foundation 2010 utilise Microsoft ASP.NET 3.5, même si une version ultérieure d’ASP.NET est installée sur le serveur Web frontal. Cependant, la version 3.5 ne modifiait pas le fichier machine.config par défaut, ni le fichier web.config global. La version antérieure la plus récente de l’application qui modifiait ces fichiers est Microsoft ASP.NET 2.0 ; par conséquent, les fichiers sont situés sous la branche de la version 2.0 du dossier %WinDir%\Microsoft.NET\Framework64\.
Le magasin de configuration IIS, hébergé dans le fichier applicationhost.config, est un troisième fichier de configuration de serveur. Ce fichier situé dans le répertoire %WinDir%\System32\inetsrv\config\ contient les inscriptions des sites Web IIS et des pools d’applications du serveur, ainsi que certains paramètres qui s’appliquent à l’ensemble des applications Web du serveur Web. Les paramètres du fichier applicationhost.config sont principalement destinés aux parties du pipeline qu’IIS utilise, tandis que le fichier machine.config et le fichier web.config global contiennent des paramètres principalement destinés aux parties du pipeline de demande intégré qu’ASP.NET utilise.
Chaque site Web IIS peut posséder son propre fichier web.config situé à sa racine, contenant les substitutions spécifiques au site des paramètres hérités des fichiers de configuration supérieurs dans la hiérarchie, ainsi que de nouveaux paramètres.
Des répertoires virtuels ou physiques particuliers d’un site Web IIS peuvent également détenir leur propre fichier web.config pour ajouter de nouveaux paramètres ou substituer des paramètres hérités. Les paramètres nouveaux ou substitués s’appliquent, bien sûr, uniquement aux demandes HTTP pour des ressources situées dans le répertoire et ses sous-répertoires.
Notes
Une application Web dans la terminologie SharePoint Foundation est étroitement liée au site Web de la terminologie IIS. Chaque application Web SharePoint Foundation est hébergée sur un site Web IIS de même nom et généralement sur un seul site Web IIS (il est possible, cependant, d’étendre une application Web SharePoint Foundation à un port supplémentaire, auquel cas celle-ci est hébergée sur un site Web IIS supplémentaire). Par conséquent, dans la documentation SharePoint Foundation, vous pourrez rencontrer des références au fichier web.config racine d’une application Web ou au fichier web.config dans un répertoire d’une application Web. Il s’agit en fait, plus précisément, de la racine et du répertoire du site Web IIS correspondant.
Le schéma XML utilisé dans ces fichiers de configuration est décrit à la rubrique IIS 7.0: Settings Schema. Voir aussi ASP.NET Configuration Overview et Le système de configuration dans IIS 7.0 (éventuellement en anglais).
Le pipeline de demande
Lorsqu’un serveur Web frontal reçoit une demande émanant d’un client, celle-ci est transmise via un pipeline constitué d’unités qui traitent la demande. Ce traitement comprend l’authentification de l’utilisateur, la vérification de l’autorisation de cet utilisateur, la génération de la réponse, l’envoi de la réponse, et finalement, la journalisation de la demande. Historiquement, certaines de ces unités sont issues des versions précédentes d’IIS et d’autres d’ASP.NET, mais la distinction de ces origines n’a pas grande importance pour SharePoint Foundation.
Gestionnaires HTTP
La réponse à toute demande est générée par un objet gestionnaire HTTP. Les demandes sont attribuées, par les fichiers *.config, à un objet gestionnaire HTTP particulier (ou à une classe de fabrique de gestionnaires qui crée des objets gestionnaires HTTP) en fonction de la ressource sollicitée et du verbe HTTP de la demande. Par exemple, dans une installation ASP.NET non modifiée, une demande de fichier aspx, c’est-à-dire d’une page ASP.NET avec le verbe GET est envoyée à un objet PageHandlerFactory qui crée un objet Page pour gérer la demande. Seules les classes qui, comme la classe Page, implémentent la classe IHttpHandler peuvent être des gestionnaires HTTP de code managé. Le mappage d’une paire ressource/verbe à un gestionnaire (ou à une fabrique de gestionnaires) est spécifié dans l’élément enfant handlers de l’élément system.webServer. L’exemple suivant illustre l’élément handlers, dont la plupart des éléments enfants sont omis à des fins de concision.
<location path="" overrideMode="Allow">
<system.webServer>
<handlers accessPolicy="Read, Script">
...
<add name="PageHandlerFactory-Integrated" path="*.aspx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.UI.PageHandlerFactory" preCondition="integratedMode" />
<add name="SimpleHandlerFactory-Integrated" path="*.ashx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.UI.SimpleHandlerFactory" preCondition="integratedMode" />
<add name="WebServiceHandlerFactory-Integrated" path="*.asmx" verb="GET,HEAD,POST,DEBUG"
type="System.Web.Services.Protocols.WebServiceHandlerFactory, System.Web.Services,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
preCondition="integratedMode,runtimeVersionv2.0" />
...
</handlers>
...
</system.webServer>
</location>
L’attribut overrideMode de l’élément location est défini sur « Allow » afin que les fichiers *.config qui sont inférieurs dans la hiérarchie puissent avoir leurs propres éléments handler qui remplacent les paramètres à cet endroit. L’attribut path est défini par une chaîne vide afin que ces paramètres s’appliquent ensuite à tous les sites Web IIS sauf s’ils sont remplacés dans un fichier *.config.
Modules HTTP
Le pipeline de demande contient également des modules HTTP. Ces modules sont des assemblys qui contiennent généralement un ou plusieurs gestionnaires d’événements ou définissent de nouveaux événements que d’autres modules peuvent gérer. Un module HTTP peut inscrire plusieurs événements dans le cycle de vie de la demande. Ils servent souvent au prétraitement ou au post-traitement des demandes. Les modules par défaut sont inscrits dans un élément enfant modules de l’élément system.webServer. L’exemple suivant illustre l’élément modules par défaut, dont la plupart des éléments enfants sont omis à des fins de concision.
<location path="" overrideMode="Allow">
<system.webServer>
...
<modules>
...
<add name="WindowsAuthentication" type="System.Web.Security.WindowsAuthenticationModule"
preCondition="managedHandler" />
<add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule"
preCondition="managedHandler" />
...
<add name="RoleManager" type="System.Web.Security.RoleManagerModule"
preCondition="managedHandler" />
<add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule"
preCondition="managedHandler" />
...
<add name="UrlMappingsModule" type="System.Web.UrlMappingsModule"
preCondition="managedHandler" />
...
</modules>
</system.webServer>
</location>
L’attribut preCondition spécifie une condition que la demande doit satisfaire pour que le module puisse s’appliquer à celle-ci. Lorsque l’attribut a la valeur « managedHandler », le module s’applique aux demandes de ressources gérées (qui sont principalement des ressources de types ASP.NET, par exemple des fichiers aspx). La section Comment SharePoint modifie-t-il le pipeline ? décrit la façon dont SharePoint Foundation substitue ce comportement afin que ces modules s’appliquent à toutes les demandes, même pour des ressources de types non-ASP.NET comme les fichiers HTML statiques. Pour plus d’informations sur les modules HTTP, voir Introduction à l’architecture IIS 7.0 (éventuellement en anglais).
Pourquoi SharePoint modifie-t-il le pipeline ?
Voici la liste des raisons qui expliquent la nécessité pour SharePoint Foundation de modifier la configuration par défaut du pipeline :
SharePoint Foundation crée un nouvel univers Web abstrait où les listes et les éléments de liste, au lieu des pages, constituent les principales entités de la population. Bien sûr, pour afficher cette population et interagir avec elle, au moins via un navigateur, les données doivent être implémentées sur les pages affichées par navigateur, courantes dans l’univers Web. Mais les listes existent indépendamment de toute page particulière et une liste donnée peut apparaître sur plusieurs pages. Par conséquent, la structure des pages d’un site Web a une moindre importance dans SharePoint Foundation à plusieurs égards.
Considérons une implication de la structuration des sites Web en fonction des listes plutôt que des pages. Un plan de site qui affiche la structure des pages a beaucoup moins d’intérêt qu’un plan qui associe les listes. Par conséquent, un plan de site de contenu de listes est beaucoup plus utile qu’un plan des pages du site.
Les gestionnaires de demandes ASP.NET généralement, voire universellement, supposent que l’URL d’une ressource demandée se mappe directement au système de fichiers du serveur Web frontal. Mais, SharePoint Foundation stocke de nombreuses ressources, comme les pages personnalisées, dans une base de données. Par ailleurs, même si un fichier est situé dans le système de fichiers du serveur Web frontal, SharePoint Foundation fait un usage considérable des répertoires virtuels, au-delà du simple mappage IIS par défaut de la racine virtuelle du serveur « \ » au répertoire physique inetpub\wwwroot\. Cette technique, entre autres raisons, est nécessaire pour que des SharePoint Foundation pages d’application fassent partie de chaque site Web dans une application Web SharePoint Foundation.
Par défaut, les modules du pipeline mis en œuvre par ASP.NET, comme le module FormsAuthentication, traitent uniquement les types de ressource associés à ASP.NET, tels que les fichiers aspx. Mais il n’y a pas de limite concernant les types de fichiers pouvant être stockées dans une bibliothèque de documents SharePoint Foundation. Pour SharePoint Foundation, toutes les demandes, indépendamment du type de ressource, doivent être traitées par ces modules. Par exemple, si un utilisateur reçoit un courrier électronique avec un lien vers un fichier .docx d’une bibliothèque de documents SharePoint Foundation, cet utilisateur doit être authentifié pour pouvoir accéder au fichier.
Par défaut, ASP.NET compile chaque page aspx dans un assembly chargé en mémoire à la première demande. Les déploiements SharePoint Foundation ont généralement trop de pages aspx pour rendre cela possible ; la mémoire des serveurs Web frontaux en serait obstruée et il n’y a pas moyen de décharger ces assemblys dynamiquement de la mémoire. Donc, SharePoint Foundation doit traiter la plupart des pages aspx en mode de décompilation.
SharePoint Foundation permet la délégation de l’administration. Bien que les serveurs et les batteries de serveurs soient toujours administrés par des informaticiens, de nombreuses tâches habituellement considérées comme destinées à des professionnels de l’informatique ou à des concepteurs de sites Web, comme créer de nouveaux sites Web ou des pages de site, sont gérées dans SharePoint Foundation par des utilisateurs considérés comme des amateurs du point de vue des professionnels de l’informatique. La délégation d’autorité à des non-professionnels nécessite un schéma plus complexe du contrôle relatif à la confiance ou aux autorisations.
En règle générale, la conception ASP.NET suppose que les nouvelles pages aspx ne sont ajoutées à un site Web que par un utilisateur ayant une autorisation d’administrateur. Par conséquent, l’application approuve tout contrôle sur une telle page. SharePoint Foundation, cependant, permet à un plus large panel d’utilisateurs d’ajouter des pages aspx : quiconque ayant l’autorisation Ajouter et personnaliser des pages peut le faire. SharePoint Foundation doit donc offrir un système permettant aux administrateurs de limiter les contrôles permis sur une page. De plus, étant donné que ces pages créées par l’utilisateur peuvent contenir des composants WebPart, les administrateurs doivent disposer d’un moyen de limiter le nombre de composants WebPart et de contrôles. Il est également nécessaire que les contrôles ajoutés par l’utilisateur et que les composants WebPart soient limités en ce qui concerne le type de code qu’ils peuvent exécuter, afin d’éviter que le code non conforme puisse entraîner un arrêt brutal du serveur Web. Pour ce faire, SharePoint exige de ces contrôles qu’ils s’exécutent dans un mode d’exécution restreint appelé mode sans échec.
SharePoint Foundation présente un modèle objet client dans un assembly qui est installé sur les ordinateurs clients. Cet assembly permet l’envoi de code au serveur et son exécution en mode différé (traitement par lots). Cela requiert la présence d’un hôte sur le serveur pour gérer les lots. Rien de la sorte n’existe dans ASP.NET, qui ne dispose d’aucun assembly côté client.
SharePoint Foundation prend en charge les flux de travail et est étroitement intégré à Windows Workflow Foundation.
SharePoint Foundation possède un système étendu de ressources globalisées qui sont référencées dans ses fichiers .aspx et .ascx. Elles nécessitent des générateurs d’expression spécialisés.
La prise en charge AJAX d’ASP.NET a été en partie reconçue pour Microsoft ASP.NET 3.5, et SharePoint Foundation prend en charge cette nouvelle conception avec des gestionnaires personnalisés.
SharePoint Foundation offre un système de limitation des demandes extrêmement configurable qui permet le blocage sélectif de demandes HTTP, lorsqu’un serveur est occupé, en fonction des caractéristiques de la demande, comme l’identité de l’agent utilisateur, le type de ressource demandée et les informations présentes dans l’en-tête.
SharePoint Foundation permet l’accès à ses sites Web à partir de périphériques mobiles. Cela s’effectue en redirigeant automatiquement les demandes des périphériques mobiles vers des versions spéciales des pages Web optimisées pour ce type de périphériques.
Comment SharePoint modifie-t-il le pipeline ?
Cette section décrit comment et où, SharePoint Foundation apporte des changements au pipeline de demande intégré au moment de l’installation. Cependant, seuls les changements les plus significatifs sont ici abordés. Les numéros en gras entre crochets, qui suivent les changements détaillés dans les sous-sections ci-dessous, renvoient à la liste sousPourquoi SharePoint modifie-t-il le pipeline ?, indiquant que cette condition est prise en charge par le changement.
Notes
En plus de modifier le pipeline, SharePoint Foundation apporte d’autres changements à la configuration des serveurs Web frontaux lors de son installation. Par exemple, il crée des sites Web IIS et des pools d’applications pour une première application Web SharePoint Foundation, pour l’application Administration centrale de SharePoint Foundation et pour la Plateforme SharePoint Services (ces deux derniers site Web et pool d’applications remplacent un pool d’applications et un site Web UDDI, supprimés par l’installation de SharePoint Foundation). Il crée également des pools d’applications pour prendre en charge Service BDC (Business Data Connectivity), les jetons de sécurité et la sécurité basée sur les revendications. Ces autres changements sont également conservés dans la hiérarchie des fichiers de configuration, mais ne sont pas abordés ici.
Changements du pipeline au niveau ASP.NET Framework
Aucun. SharePoint Foundation n’apporte aucune modification au fichier machine.config ni au fichier web.config global.
Changements du pipeline au niveau de la configuration IIS
SharePoint Foundation modifie le magasin de configuration IIS (applicationhost.config). Les changements les plus significatifs sont les suivants :
SharePoint Foundation enregistre owssvr.dll en tant que module global nommé SharePoint14Module. Cet assembly non managé sert principalement à la transmission des demandes de données des serveurs Web frontaux vers les bases de données SharePoint Foundation. Il gère les demandes de ressources non gérées adressées à une application Web SharePoint Foundation (les ressources ASP.NET, comme les fichiers ?x, sont des ressources gérées). L’inscription d’un assembly non managé met celui-ci à la disposition de sites Web IIS particuliers (et, par conséquent, d’applications Web SharePoint Foundation) pour leur usage propre (il n’est pas nécessaire d’inscrire les modules managés globalement). Pour plus d’informations sur owssvr.dll, voir Protocole RPC (Remote Procedure Call) et les rubriques associées. L’exemple suivant illustre l’inscription (les sauts de ligne dans le chemin d’accès n’apparaissent pas dans l’original). [2 et 3]
Notes
Tous les extraits des fichiers de configuration SharePoint Foundation de cette rubrique proviennent d’une version préliminaire de SharePoint Foundation. Ils sont fournis à des fins d’illustration et ne correspondent pas nécessairement au contenu de ces fichiers dans la version finale du produit.
<system.webServer> ... <globalModules> ... <!-- Other Unmanaged Modules --> ... <add name="SharePoint14Module" image="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\owssvr.dll" /> </globalModules> </system.webServer>Certains départements informatiques souhaitent limiter les extensions ISAPI exécutables sur leurs serveurs à celles spécifiquement détaillées dans une section <isapiCgiRestriction> du fichier applicationhost.config. Pour répondre à ces exigences, SharePoint Foundation ajoute owssvr.dll et trois assemblys étroitement liés à cette section. L’exemple suivant illustre l’inscription (les sauts de ligne dans le chemin d’accès n’apparaissent pas dans l’original). [2]
<system.webServer> ... <security> ... <isapiCgiRestriction notListedIsapisAllowed="false" notListedCgisAllowed="false"> ... <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\_vti_aut\author.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\_vti_adm\admin.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\shtml.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> <add path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions \14\isapi\owssvr.dll" allowed="true" groupId="Windows SharePoint Services V4" description="Windows SharePoint Services V4" /> </isapiCgiRestriction> ... </security> ... </system.webServer>Une section <site> est créée dans applicationhost.config chaque fois que SharePoint Foundation crée un site Web IIS et un pool d’applications pour une application Web SharePoint Foundation. Le but principal de cette section est de mapper des répertoires virtuels à des répertoires physiques avec des éléments virtualDirectory. L’exemple suivant est un extrait d’une section <site> (les sauts de ligne dans les chemins d’accès n’apparaissent pas dans l’original). [2]
<site name="SharePoint - 80" id="2055865624" serverAutoStart="true"> <application path="/" applicationPool="SharePoint - 80"> <virtualDirectory path="/" physicalPath="C:\inetpub\wwwroot\wss\VirtualDirectories\80" /> <virtualDirectory path="/_vti_bin" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\isapi" /> <virtualDirectory path="/_layouts" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\template\layouts" /> <virtualDirectory path="/_controltemplates" physicalPath="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\template\controltemplates" /> ... </application> ... </site>
Changements du pipeline au niveau de l’application Web SharePoint
À la création d’une application Web SharePoint Foundation (et d’un site Web IIS correspondant), un fichier web.config est ajouté à sa racine. Ce fichier contient les paramètres de configuration suivants, qui s’ajoutent, ou se substituent, aux paramètres des niveaux supérieurs dans la hiérarchie de configuration. Pour plus d’informations sur ce fichier et sur la façon de le modifier dans des projets de développement SharePoint Foundation, voir Utiliser des fichiers Web.config.
Une section <SafeMode> permet de configurer le système de traitement du mode sans échec. Voici l’élément SafeModeSharePoint Foundation standard immédiatement après l’installation. Notez que l’attribut CallStack a la valeur false. Cela a pour effet de bloquer la plupart des informations sur les exceptions système qui sont normalement signalées par ASP.NET. Cela permet d’éviter une divulgation des informations. [5 et 6]
SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false"> ... </SafeMode>Une section <SafeControls> spécifie les contrôles autorisés à s’exécuter en mode sans échec. Les pages de site personnalisées s’exécutent en mode sans échec, mais pas les pages d’application. Cela permet de s’assurer que les utilisateurs ne peuvent pas ajouter une page de site comprenant un contrôle n’ayant pas une autorisation d’administrateur pour s’exécuter sur une page de site (les utilisateurs n’ont pas le droit d’ajouter des pages d’application). Chaque élément SafeControl de la section peut enregistrer une classe de contrôle particulière dans un assembly comme étant sécurisée, ou plusieurs classes en utilisant des caractères génériques. Vous pouvez ajouter vos propres éléments SafeControl supplémentaires au fichier dans le cadre du déploiement de votre projet de développement. Pour plus d’informations sur la manière de procéder, voir Comment : créer un fichier .config supplémentaire et SafeControl, élément (Solution). L’exemple suivant est un extrait de la section <SafeControls>. [5 et 6]
<SharePoint> ... <SafeControls> <SafeControl Assembly="System.Web, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" TypeName="*" Safe="True" AllowRemoteDesigner="True" /> ... <!-- Other ASP.NET classes --> ... <SafeControl Assembly="System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" Namespace="System.Web.UI.WebControls" TypeName="SqlDataSource" Safe="False" AllowRemoteDesigner="False" /> ... <!-- SharePoint classes from earlier versions of the SharePoint assemblies --> ... <SafeControl Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint" TypeName="*" Safe="True" AllowRemoteDesigner="True" /> ... <!-- Other SharePoint classes from the current version of the SharePoint assemblies --> ... <SafeControl Src="~/_controltemplates/*" IncludeSubFolders="True" Safe="True" AllowRemoteDesigner="True" /> ... </SafeControls> ... </SharePoint>Notez que le dernier élément SafeControl de l’extrait enregistre comme sécurisés les contrôles ascx non compilés dans le répertoire virtuel _controltemplates, qui correspond au répertoire %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\CONTROLTEMPLATES.
Une section <pages> est ajoutée. Elle identifie le filtre analyseur de page SharePoint Foundation personnalisé (dérivé de PageParserFilter) qui filtre les contrôles non sécurisés. Le filtre détermine également si la page doit être compilée ou traitée en mode non compilé. L’inscription est illustrée dans le code suivant. [4, 5 et 6]
<pages enableSessionState="false" enableViewState="true" enableViewStateMac="true" validateRequest="false" pageParserFilterType="Microsoft.SharePoint.ApplicationRuntime.SPPageParserFilter, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" asyncTimeout="7"> ... </pages>Une section <modules> remplace la configuration héritée de la manière suivante :
L’attribut runAllManagedModulesForAllRequests est défini sur true. Cela a pour effet de remplacer la condition « managedHandler » prédéfinie dans le magasin de configuration IIS et, donc, les parties code managé du pipeline (y compris celles mises en œuvre par ASP.NET, comme l’authentification de l’utilisateur) s’appliquent à toutes les demandes, indépendamment du fait que la ressource demandée soit de type gérée ou soit associée à ASP.NET. [3]
Certains modules inutilisés par SharePoint Foundation sont supprimés et d’autres sont ajoutés, notamment SharePoint14Module, une autre appellation du fichier owssvr.dll (ce module non géré est inscrit dans le magasin de configuration IIS en tant que module global ; il doit être activé ici pour l’utilisation par cette application Web). [2]
SPRequestModule est également ajouté. Ce module géré effectue les tâches suivantes :
Inscrit le fournisseur de chemins d’accès virtuels SharePoint Foundation, un objet d’une classe interne qui implémente VirtualPathProvider. Le fournisseur de chemins d’accès sert d’interpréteur URL. Par exemple, si une demande de page de site que le propriétaire du site a personnalisée est reçue, l’URL semble pointer vers un emplacement dans le système de fichiers physique ; mais le fournisseur de chemins d’accès SharePoint Foundation traduit l’URL par un emplacement dans la base de données de contenu. Le fournisseur de chemins d’accès permet également à SharePoint Foundation de prendre en charge deux types différents d’URL : URL relative au serveur et URL relative au site. Il résout les jetons « ~ » qui apparaissent dans certains chemins d’accès, comme ceux des fichiers de page maître. Il vérifie si un fichier demandé dans une bibliothèque de documents est extrait. Finalement, le fournisseur de chemins d’accès interprète les URL contenant des dossiers virtuels et les résout vers l’URL physique réelle. Après avoir récupéré une page aspx, le fournisseur de chemins d’accès la passe au filtre analyseur de page, qui détermine si elle contient du code non sécurisé. Si cela n’est pas le cas, le fichier est transmis à l’analyseur de page ASP.NET. [2]
Détermine si une demande doit être acheminée vers owssvr.dll, auquel cas il effectue un traitement sur les en-têtes HTTP de la demande requis par owssvr.dll. [2 et 3]
Régit le système de surveillance des performances et de limitation des demandes. Il peut de manière sélective bloquer des demandes lorsqu’un serveur est trop occupé pour gérer toutes les demandes qu’il reçoit. [11]
Détermine si la demande émane d’un périphérique mobile, auquel cas elle est transmise à la page mobile appropriée. [12]
L’exemple suivant illustre la section <modules>.
<system.webServer> ... <modules runAllManagedModulesForAllRequests="true"> <remove name="AnonymousIdentification" /> <remove name="FileAuthorization" /> <remove name="Profile" /> <remove name="WebDAVModule" /> <add name="SPRequestModule" preCondition="integratedMode" type="Microsoft.SharePoint.ApplicationRuntime.SPRequestModule, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="ScriptModule" preCondition="integratedMode" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="SharePoint14Module" preCondition="integratedMode" /> </modules> ... </system.webServer>
Une section <handlers> remplace la configuration héritée, principalement en supprimant certains gestionnaires HTTP que SharePoint Foundation n’utilise pas et en ajoutant les gestionnaires qui prennent en charge AJAX. owssvr.dll est inscrit en tant que gestionnaire HTTP sous le nom OwssvrHandler. Cela est nécessaire afin que les demandes lui soient acheminées lors de l’événement MapRequestHandler (les demandes de ressources non gérées sont traitées par OwssvrHandler). Pour plus d’informations sur les événements dans le cycle de vie de la demande, voir ASP.NET Application Life Cycle Overview for IIS 7.0. L’exemple suivant illustre la section <handlers> (les sauts de ligne dans les chemins d’accès n’apparaissent pas dans l’original). [3 et 10]
<system.webServer> ... <handlers> <remove name="OPTIONSVerbHandler" /> <remove name="WebServiceHandlerFactory-Integrated" /> <remove name="svc-Integrated" /> <remove name="WebDAV" /> <add name="svc-Integrated" path="*.svc" verb="*" type="System.ServiceModel.Activation.HttpHandler, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" preCondition="integratedMode" /> <add name="OwssvrHandler" scriptProcessor="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\isapi\owssvr.dll" path="/_vti_bin/owssvr.dll" verb="*" modules="IsapiModule" preCondition="integratedMode" /> <add name="ScriptHandlerFactory" verb="*" path="*.asmx" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="ScriptHandlerFactoryAppServices" verb="*" path="*_AppService.axd" preCondition="integratedMode" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add name="ScriptResource" preCondition="integratedMode" verb="GET,HEAD" path="ScriptResource.axd" type="System.Web.Handlers.ScriptResourceHandler, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> </handlers> </system.webServer>Une section <microsoft.sharepoint.client> est ajoutée pour prendre en charge le modèle objet client de SharePoint Foundation et la programmation côté client (pour en savoir plus sur ce modèle objet, voir Utilisation des API clientes). L’exemple de code suivant montre cette section. [7]
<microsoft.sharepoint.client> <serverRuntime> <hostTypes> <add type="Microsoft.SharePoint.Client.SPClientServiceHost, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </hostTypes> </serverRuntime> </microsoft.sharepoint.client>Plusieurs sections sont ajoutées pour prendre en charge les limites relatives aux composants WebPart et au nombre de contrôles. [5 et 6]
<WebPartLimits MaxZoneParts="50" PropertySize="1048576" /> <WebPartCache Storage="CacheObject" /> <WebPartControls DatasheetControlGuid="65BCBEE4-7728-41a0-97BE-14E1CAE36AAE" />Une section <WorkflowServices> et une section <System.Workflow.ComponentModel.WorkflowCompiler> sont ajoutées pour prendre en charge les flux de travail dans SharePoint Foundation. L’exemple de code suivant montre la section <WorkflowServices> et, en dessous, un extrait de la section <System.Workflow.ComponentModel.WorkflowCompiler>.[8]
<SharePoint> ... <WorkflowServices> <WorkflowService Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Class="Microsoft.SharePoint.Workflow.SPWinOEWSSService"> </WorkflowService> <WorkflowService Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Class="Microsoft.SharePoint.Workflow.SPWinOETaskService"> </WorkflowService> </WorkflowServices> </SharePoint> ... <System.Workflow.ComponentModel.WorkflowCompiler> <authorizedTypes> <authorizedType Assembly="System.Workflow.Activities, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" /> <authorizedType Assembly="System.Workflow.ComponentModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.*" TypeName="*" Authorized="True" /> <authorizedType Assembly="System.Workflow.Runtime, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Namespace="System.Workflow.Runtime" TypeName="CorrelationToken" Authorized="True" /> <authorizedType Assembly="mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" Namespace="System" TypeName="Guid" Authorized="True" /> ... <-- Other mscorlib classes --> ... <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowActivationProperties" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowTaskProperties" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowHistoryEventType" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPItemKey" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.Workflow" TypeName="SPWorkflowUserContext" Authorized="True" /> <authorizedType Assembly="Microsoft.SharePoint.WorkflowActions, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" Namespace="Microsoft.SharePoint.WorkflowActions" TypeName="*" Authorized="True" /> </authorizedTypes> </System.Workflow.ComponentModel.WorkflowCompiler>Une section <securityPolicy> est utilisée pour ajouter deux niveaux de confiance supplémentaires, WSS_Minimal et WSS_Medium. Ces niveaux de confiance sont définis dans des fichiers situés dans le répertoire %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG. L’exemple de code suivant montre la section <securityPolicy> (les sauts de ligne dans les chemins d’accès n’apparaissent pas dans l’original). [5]
<system.web> <securityPolicy> <trustLevel name="WSS_Medium" policyFile="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\config\wss_mediumtrust.config" /> <trustLevel name="WSS_Minimal" policyFile="C:\Program Files\Common Files\Microsoft Shared \Web Server Extensions\14\config\wss_minimaltrust.config" /> </securityPolicy> ... </system.web>Une section <compilation> signale à l’analyseur de page quatre assemblys supplémentaires qu’il peut utiliser pour compiler les fichiers SharePoint Foundation as?x. Elle spécifie également quatre générateurs d’expression spéciaux que l’analyseur de page utilise pour traiter les pages ASP.NET et d’autres contrôles as?x dans une application Web SharePoint Foundation. L’exemple de code suivant montre la section <compilation>. [9]
<system.web> ... <compilation batch="false" debug="false"> <assemblies> <add assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" /> <add assembly="Microsoft.Web.CommandUI, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add assembly="Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </assemblies> <expressionBuilders> <remove expressionPrefix="Resources" /> <add expressionPrefix="Resources" type="Microsoft.SharePoint.SPResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SPHtmlEncodedResources" type="Microsoft.SharePoint.SPHtmlEncodedResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SPSimpleFormattingEncodedResources" type="Microsoft.SharePoint.SPSimpleFormattingEncodedResourceExpressionBuilder, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add expressionPrefix="SatelliteResources" type="Microsoft.SharePoint.Search.SPSatelliteResourceExpressionBuilder, Microsoft.SharePoint.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </expressionBuilders> </compilation> ... </system.web>Une section <sitemap> spécifie quatre fournisseurs spéciaux de plan de site SharePoint Foundation. L’exemple de code suivant montre la section <sitemap>. [1]
<system.Web> ... <siteMap defaultProvider="SPSiteMapProvider" enabled="true"> <providers> <add name="SPNavigationProvider" type="Microsoft.SharePoint.Navigation.SPNavigationProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPSiteMapProvider" type="Microsoft.SharePoint.Navigation.SPSiteMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPContentMapProvider" type="Microsoft.SharePoint.Navigation.SPContentMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> <add name="SPXmlContentMapProvider" siteMapFile="_app_bin/layouts.sitemap" type="Microsoft.SharePoint.Navigation.SPXmlContentMapProvider, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" /> </providers> </siteMap> ... </system.Web>
Notes
L’application Administration centrale de SharePoint Foundation est implémentée comme une application Web SharePoint Foundation, et par conséquent comme un site Web IIS. Elle possède également un fichier web.config racine très similaire au fichier web.config décrit ci-dessus. Les principales différences sont que l’application Administration centrale prend en charge les états de session et inscrit des fournisseurs de plan de site supplémentaires et certains contrôles supplémentaires comme sécurisés. Le site Web IIS qui héberge la Plateforme SharePoint Services possède également un petit fichier web.config racine. Il est utilisé pour inscrire des fournisseurs qui prennent en charge la sécurité basée sur les revendications.
Changements du pipeline au niveau des répertoires
SharePoint Foundation affine davantage le pipeline de demande avec des fichiers web.config qui s’appliquent uniquement aux demandes de ressources au sein de répertoires virtuels ou physiques particuliers. Un simple exemple est donné ici : SharePoint Foundation fournit des versions de ses pages et formulaires d’application conçus pour l’affichage sur des périphériques mobiles. Ils sont situés dans le répertoire virtuel _layouts\mobile (qui correspond au répertoire physique %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\LAYOUTS\MOBILE\). Ce répertoire contient un fichier web.config qui définit des limites relatives à la quantité de données affichées sur la page. Il inscrit également une série de filtres qui contrôlent le rendu de la page, en fonction des capacités du périphérique mobile qui a demandé la page.
Voir aussi
Autres ressources
ASP.NET Application Life Cycle Overview for IIS 7.0
ASP.NET Configuration Overview
Introduction à l’architecture IIS 7.0 (éventuellement en anglais)
Le système de configuration dans IIS 7.0 (éventuellement en anglais)