Déploiement de composants WebPart dans SharePoint Foundation

Article
09/24/2014

Dernière modification : jeudi 1 septembre 2011

S’applique à : SharePoint Foundation 2010

Dans cet article
Considérations sur le déploiement
Considérations relatives aux autorisations de sécurité
Attribution d'un nom fort à un assembly de composant WebPart
Création d'une entrée SafeControl
Création d'un fichier .Webpart

Dans Microsoft SharePoint Foundation, il faut déployer un composant WebPart dans la galerie de composants WebPart avant de l’ajouter à une page Web. Cette section explique les différences entre le dossier bin et le GAC (Global Assembly Cache), aborde également le sujet des autorisations de sécurité et indique comment attribuer un nom fort à un assembly pour le déploiement, comment créer une entrée SafeControl et comment créer un fichier de définition de composant WebPart pour déployer ce composant.

Considérations sur le déploiement

Un site SharePoint offre plusieurs emplacements possibles pour déployer un assembly de composant WebPart.

Galerie de solutions — La galerie de solutions est l’emplacement recommandé pour déployer un composant WebPart à l’aide d’une solution en bac à sable (sandbox). Elle offre par défaut des fonctionnalités de surveillance et de sécurité pour vos composants WebPart. Pour plus d’informations sur les solutions en bac à sable (sandbox), voir Solutions en mode bac à sable.
Répertoire bin — Le répertoire bin est un dossier stocké dans le répertoire racine de votre application Web. L’emplacement de ce dossier est déterminé lors de la création du site Web dans les services Internet (IIS). Dans SharePoint Foundation, cela peut se produire soit par le biais du site Administration centrale soit en créant manuellement un nouveau site Web dans le gestionnaire IIS.

Important

S'il n'existe pas de répertoire bin, vous devez en ajouter un manuellement. Ne stockez pas de composants WebPart dans le répertoire _app_bin local, réservé à Microsoft.

Pour plus d'informations, voir Procédure : rechercher la racine de votre application Web

Global Assembly Cache — Emplacement global où peuvent être déployés les assemblys signés. Ce cache vous permet de partager des assemblys entre de nombreuses applications. Il est installé automatiquement avec le runtime .NET. D’une façon générale, les composants sont installés dans le dossier C:\WINNT\Assembly.

Chaque emplacement de déploiement présente des avantages et des inconvénients, comme le décrit le tableau qui suit.

Emplacement de déploiement	Avantages	Inconvénients
Galerie de solutions	Par défaut, le code déployé dans la galerie de solutions est exécuté avec une confiance partielle. En outre, le code dans la galerie de solutions fait l’objet d’une surveillance de l’utilisation des ressources afin que soit garantie l’intégrité de la batterie de serveurs. La galerie de solutions est spécifique à une collection de sites.	Aucune partie du modèle objet dans SharePoint Foundation n’est disponible dans la galerie de solutions.
Répertoire bin	Les assemblys s'exécutent avec un degré de confiance partiel par défaut. Le code qui est exécuté à partir de ce répertoire possède un faible niveau d'autorisations pour la sécurité d'accès du code (CAS). Étant donné que les administrateurs doivent élever explicitement des autorisations ayant été accordées à un composant WebPart afin qu'il fonctionne correctement, ils préfèrent souvent que les assemblys soient exécutés dans le répertoire bin, avec un ensemble défini d'autorisations CAS requises. Un répertoire bin est spécifique à une application Web. Cela permet d'isoler le code pour une application Web en particulier.	Pour que le composant WebPart s'exécute dans plusieurs applications Web, vous devez le déployer dans le Global Assembly Cache.
Global Assembly Cache	Par défaut, les assemblys s'exécutent avec un niveau d'autorisation totale. Ils sont généralement installés globalement et peuvent donc fonctionner dans n'importe quelle application Web. Le Global Assembly Cache peut contenir plusieurs versions du même assembly.	Généralement, il n’existe aucune restriction CAS sur le code installé dans le Global Assembly Cache. De plus, un assembly déployé dans le GAC est mis en cache, de sorte que s'il est reconstruit, il n'est pas mis à jour automatiquement sur le site SharePoint. Vous devez obliger SharePoint Foundation à recharger l'assembly en réinitialisant les services Internet (IIS).

Galerie de solutions

Par défaut, le code déployé dans la galerie de solutions est exécuté avec une confiance partielle. En outre, le code dans la galerie de solutions fait l’objet d’une surveillance de l’utilisation des ressources afin que soit garantie l’intégrité de la batterie de serveurs. La galerie de solutions est spécifique à une collection de sites.

Aucune partie du modèle objet dans SharePoint Foundation n’est disponible dans la galerie de solutions.

Répertoire bin

Les assemblys s'exécutent avec un degré de confiance partiel par défaut. Le code qui est exécuté à partir de ce répertoire possède un faible niveau d'autorisations pour la sécurité d'accès du code (CAS). Étant donné que les administrateurs doivent élever explicitement des autorisations ayant été accordées à un composant WebPart afin qu'il fonctionne correctement, ils préfèrent souvent que les assemblys soient exécutés dans le répertoire bin, avec un ensemble défini d'autorisations CAS requises.

Un répertoire bin est spécifique à une application Web. Cela permet d'isoler le code pour une application Web en particulier.

Pour que le composant WebPart s'exécute dans plusieurs applications Web, vous devez le déployer dans le Global Assembly Cache.

Global Assembly Cache

Par défaut, les assemblys s'exécutent avec un niveau d'autorisation totale. Ils sont généralement installés globalement et peuvent donc fonctionner dans n'importe quelle application Web. Le Global Assembly Cache peut contenir plusieurs versions du même assembly.

Généralement, il n’existe aucune restriction CAS sur le code installé dans le Global Assembly Cache.

De plus, un assembly déployé dans le GAC est mis en cache, de sorte que s'il est reconstruit, il n'est pas mis à jour automatiquement sur le site SharePoint. Vous devez obliger SharePoint Foundation à recharger l'assembly en réinitialisant les services Internet (IIS).

Considérations relatives aux autorisations de sécurité

Par défaut, les autorisations de sécurité d'accès du code pour le répertoire bin sont faibles ; seule l'exécution pure est autorisée. Dans la plupart des cas, vous devez élever ces autorisations pour que votre assembly s'exécute correctement, par exemple si votre composant WebPart requiert l'accès au modèle objet SharePoint.

Il existe deux façons d'élever les autorisations :

Méthode conseillée — Créez un nouveau fichier de stratégie d'approbation et faites pointer votre fichier web.config sur ce nouveau fichier. Cette méthode est plus compliquée, mais elle permet d'attribuer précisément les autorisations pour vos composants WebPart.

Pour plus d'informations sur les fichiers de stratégie d'approbation, voir Sécurisation des composants WebPart dans SharePoint Foundation.
Méthode facultative — Augmentez le niveau de confiance du répertoire bin. Dans le fichier web.config de la racine de l’application Web se trouve une balise appelée <trust>, avec l’attribut par défaut level="WSS_Minimal". Vous pouvez changer ce niveau et choisir WSS_Medium. Cette méthode est plus simple, mais elle accorde arbitrairement de nouvelles autorisations dont vous n’avez pas forcément besoin et elle est moins sécurisée que celle qui consiste à créer un nouveau fichier de stratégie d’approbation.

Attribution d'un nom fort à un assembly de composant WebPart

Les noms forts utilisent une clé privée pour signer numériquement un assembly. En outre, ils estampillent l'assembly avec une clé publique pour valider la signature. Cette technique permet de lutter contre les versions non autorisées d'un composant WebPart. Si la clé publique ne peut pas valider la signature numérique, SharePoint Foundation refuse d'exécuter le module.

Pour le déploiement d'un composant WebPart dans le répertoire bin, il est recommandé d'utiliser un nom fort pour l'assembly. Lors du déploiement d'un composant WebPart dans le Global Assembly Cache, l'assembly doit avoir un nom fort. Un assembly sans nom fort n'est pas recommandé dans SharePoint Foundation.

Pour signer un assembly, utilisez l’outil sn.exe fourni avec le Kit de développement logiciel (SDK) Microsoft .NET Framework. Pour plus d’informations sur ce Kit de développement logiciel, voir Téléchargement de .NET Framework 2.0. L’outil sn.exe permet également d’extraire la clé publique requise pour inscrire votre contrôle comme étant sûr dans la liste SafeControls. Pour plus d’informations sur l’utilisation de l’outil sn.exe, voir Outil Strong Name Tool (Sn.exe).

Création d'une entrée SafeControl

La technologie SharePoint Foundation repose sur une hypothèse fondamentale selon laquelle des utilisateurs non approuvés peuvent créer et télécharger des pages ASPX sur le système où s'exécute SharePoint Foundation. Pour empêcher les utilisateurs non approuvés d'ajouter arbitrairement du code côté serveur dans les pages ASPX, SharePoint Foundation fournit une liste SafeControls.

La liste SafeControls est une liste de contrôles approuvés et de composants WebPart spécifiques du site SharePoint que vous avez désigné comme étant sécurisé pour l'appel par n'importe quelle page ASPX de votre site Web. Cette liste se trouve dans le fichier web.config à la racine de votre application Web.

Une entrée SafeControl est une déclaration XML d'un composant WebPart avec la syntaxe suivante.

<SafeControl Assembly="AssemblyNameWithoutDLLExtension, Version=AssemblyVersionNumber, Culture=neutral, PublicKeyToken=PublicKeyToken" Namespace="NamespaceOfYourProject" TypeName="*" Safe="True" />

L'entrée SafeControl utilise le nom de l'assembly, l'espace de noms, les informations de gestion des versions et, s'il est signé, elle requiert également un jeton de clé publique pour vérifier que le contrôle est sûr. Si un assembly de composant WebPart est signé, vous pouvez utiliser l'outil Strong Name pour récupérer le jeton de clé publique à utiliser dans l'entrée SafeControl. La commande suivante récupère le jeton de clé publique pour un assembly.

sn -T AssemblyName.dll

Création d'un fichier .Webpart

Un fichier de définition de composant WebPart est un simple fichier XML qui contient les paramètres de propriété pour un seul composant WebPart. Pour importer votre composant WebPart dans une page de composants WebPart, téléchargez simplement le fichier .webpart ou ajoutez le composant à la galerie de composants WebPart. Après avoir téléchargé le composant WebPart, vous pouvez l’afficher en l’ajoutant à une page de site. Pour afficher un nom et une description par défaut pour le composant WebPart après son importation, vous devez inclure les propriétés Title et Description dans le fichier de définition du composant WebPart. Si vous souhaitez définir d’autres propriétés du composant WebPart lors de l’importation, vous pouvez également les définir dans un fichier .webpart. Un fichier .webpart utilise la syntaxe suivante.

<?xml version="1.0" encoding="utf-8" ?> 
  <webParts>
     <webPart xmlns="https://schemas.microsoft.com/WebPart/v3">
       <metaData>
         <type name="TypeName, Version=VersionNumber, Culture=neutral, 
         PublicKeyToken=PublicKeyToken" /> 
         <importErrorMessage>Cannot import this Web 
         Part.</importErrorMessage> 
       </metaData>
       <data>
         <properties>
           <property name="Title" type="string">
              WebPartTitle</property>
           <property name="Description" type="string">
              WebPartDescription
           </property>
         </properties>
       </data>
     </webPart>
   </webParts>

SharePoint Foundation prend également en charge les fichiers .dwp pour les composants WebPart. L’exportation d’un composant WebPart peut être réalisée au travers d’un fichier .dwp ou d’un fichier .webpart. Pour plus d’informations, voir Mise à niveau des composants WebPart.