Architecture des solutions en bac à sable (sandbox)

Cette rubrique décrit l'architecture d'un système de solutions en bac à sable (sandbox) dans SharePoint.

Dernière modification : jeudi 14 avril 2011

S’applique à : SharePoint Foundation 2010

Dans cet article
Vue d'ensemble
Système de packaging et d'installation pour les solutions en bac à sable (sandbox)
Modèle de traitement pour les solutions en bac à sable (sandbox)
Exécution de code et accès aux ressources dans le processus de travail en sandbox
Restrictions de l'utilisation des ressources sur les solutions en bac à sable (sandbox)
Système de rendu des pages fractionnées
Contournement des restrictions imposées aux solutions en bac à sable (sandbox)
Infrastructure de validation de solution

Disponible dans SharePoint Online

Sont incluses les descriptions du système de packaging, du modèle de traitement, du système de rendu des pages fractionnées, des restrictions d'utilisation des ressources, des restrictions d'exécution et d'accès du code, ainsi que de l'infrastructure de validation de solution. Des informations détaillées sur ces sujets sont disponibles dans les rubriques du nœud Solutions en mode bac à sable du Kit de développement logiciel (SDK).

Vue d'ensemble

Une solution en bac à sable (sandbox), par opposition à une solution de batterie de serveurs, permet aux administrateurs de collections de sites d'installer des solutions personnalisées dans Microsoft SharePoint Foundation sans impliquer un administrateur de niveau supérieur. Cette liberté, toutefois, requiert que les solutions en bac à sable (sandbox) se limitent à ce qu'ils peuvent déployer, au code qu'ils peuvent exécuter et aux ressources auxquelles ils peuvent accéder.

Système de packaging et d'installation pour les solutions en bac à sable (sandbox)

À l'instar d'une solution de batterie de serveurs, une solution en bac à sable (sandbox) est packagée pour son installation dans un fichier de package de solution (.wsp). En revanche, au lieu d'être déployées dans le magasin de solution de la batterie de serveurs, les solutions en bac à sable (sandbox) sont déployées dans la Galerie de solutions d'une collection de sites spécifique par un administrateur de collection de sites. La galerie est une liste SharePoint spéciale, donc elle se trouve dans la base de données de contenu. Le déploiement de solutions dans la galerie s'effectue via l'interface utilisateur Actions du site de la collection de sites ou à l'aide d'un SharePoint Management Shell. Pour plus d'informations sur le processus d'installation des solutions en bac à sable (sandbox), voir Installation, désinstallation et mise à niveau des solutions en bac à sable (sandbox).

Il existe des limites sur les types d'éléments pouvant être inclus dans les solutions en bac à sable (sandbox) et sur les emplacements auxquels ils peuvent être déployés. Le plus important est que rien ne peut être déployé dans le système de fichiers des serveurs à partir d'une solution en bac à sable (sandbox). Cette restriction comporte plusieurs implications :

• Les pages d'application, les contrôles utilisateur (fichiers .ascx) et les fichiers de ressources de localisation (.resx) ne peuvent pas être déployés avec une solution en bac à sable (sandbox). (Il existe cependant d'autres moyens pour localiser des solutions en bac à sable (sandbox). Pour plus d’informations, voir Localisation de solutions en mode bac à sable (sandbox).)

• Les images, les fichiers de script et les fonctionnalités inclus dans les solutions en bac à sable (sandbox) sont déployés dans la base de données de contenu, et non dans le système de fichiers des serveurs frontaux.

• Les définitions de site ne peuvent pas être déployées dans des solutions en bac à sable (sandbox). (Mais les modèles Web, qui sont équivalents d'un point de vue fonctionnel, le peuvent. Pour plus d’informations, voir How to: Deploy a Web Template in a Sandboxed Solution.)

• Les assemblys inclus dans des solutions en bac à sable (sandbox) sont également déployés dans la base de données de contenu, bien que, lorsqu'ils sont utilisés, ils soient temporairement mis en cache dans le système de fichiers du serveur qui gère la requête. Pour plus d’informations, voir Où les assemblys sont-ils déployés dans les solutions en bac à sable (sandbox) ?.

Pour en savoir plus sur ce qui peut être déployé dans une solution en bac à sable (sandbox), voir Qu'est-ce qui peut être implémenté dans une solution en bac à sable (sandbox) ?.

Une solution en bac à sable (sandbox) n'est également pas autorisée à accéder à tout ce qui se trouve en dehors de la collection de sites dans laquelle elle est déployée. Cette restriction implique alors que les fonctionnalités déployées dans les solutions en bac à sable (sandbox) peuvent uniquement s'étendre à une collection de sites ou à un site Web.

Modèle de traitement pour les solutions en bac à sable (sandbox)

SharePoint est une application ASP.NET et à l'instar de toute application ASP.NET, lorsqu'une requête HTTP est reçue par un serveur Web frontal, un pilote spécial, HTTP.SYS, détecte la requête et l'achemine vers le pool d'applications qui gère les requêtes pour le site Web IIS ciblé, et par conséquent, l'application Web SharePoint ciblée. Chaque pool d'applications possède un processus de travail IIS (w3wp.exe) au cours duquel la chaîne de requête de chaque requête est exécutée. (Pour plus d'informations sur les processus de travail IIS 7.0 et les pools d'applications, voir Introduction to IIS 7 Architecture (Présentation de l'architecture IIS 7) (éventuellement en anglais).) Sur un serveur SharePoint, le processus de travail IIS s'exécute dans le compte du pool d'applications. Il s'agit en principe du compte de la batterie de serveurs et ainsi, le processus dispose d'autorisations en lecture et en écriture sur les ressources SharePoint. Sur une batterie de serveurs multiserveur, le compte de la batterie de serveurs correspond en principe à un utilisateur de domaine. Il s'agit du même compte que celui qui accède aux bases de données de contenu. Le service du minuteur SharePoint 2010 s'exécute dans le contexte du même compte.

Les solutions de batterie de serveurs s'exécutent dans le processus de travail IIS à l'instar de toute application ASP.NET. Les solutions en bac à sable (sandbox), en revanche, s'exécutent dans un environnement d'exécution spécialement restreint. Cette restriction est nécessaire afin d'empêcher le code non autorisé ou peu performant de ralentir ou bloquer le pool d'applications. En conséquence, SharePoint impose des restrictions sur ce que le code peut faire dans une solution en bac à sable (sandbox). Dans le cadre crucial de l'implémentation de ce système, les solutions en bac à sable (sandbox) doivent s'exécuter dans un processus de travail en sandbox spécial (SPUCWorkerProcess.exe).

Lorsqu'une requête essaie d'accéder à une solution en bac à sable (sandbox), un gestionnaire d'exécution SharePoint qui s'exécute dans le processus de travail IIS recherche un processus de travail en sandbox (ou en démarre un, si aucun n'est en cours d'exécution) dans lequel exécuter le code de la solution en bac à sable (sandbox). En principe, il est possible de démarrer ce processus de travail en sandbox sur n'importe quel serveur de la batterie de serveurs qui exécute le Service de code en mode bac à sable Microsoft SharePoint Foundation (SPUCHostService.exe). Dans la boîte de dialogue Services de Windows, ce service est appelé Hôte de code utilisateur SharePoint 2010.

Le serveur qui exécute le Service de code en mode bac à sable Microsoft SharePoint Foundation peut être, mais ne doit pas nécessairement être, le serveur Web frontal sur lequel le processus de travail IIS s'exécute. Il est possible de configurer le serveur utilisé dans l'application Administration centrale : les administrateurs peuvent choisir d'exécuter chaque processus en sandbox en « mode local », ce qui signifie que chaque demande de solution en bac à sable (sandbox) est traitée sur le même serveur Web frontal que celui sur lequel le processus de travail IIS s'exécute ; ou ils peuvent utiliser le gestionnaire d'exécution pour lancer chaque processus en sandbox en « mode distant », parfois appelé « mode d'affinité ». Dans ce dernier mode, le gestionnaire d'exécution recherche un serveur qui exécute le Service de code en mode bac à sable Microsoft SharePoint Foundation et qui a déjà créé un domaine d'application à l'intérieur de son processus SPUCWorkerProcess.exe pour cette même solution en bac à sable (sandbox). (C'est le cas si cette même solution en bac à sable (sandbox) a été demandée auparavant, éventuellement par un autre utilisateur sur une autre collection de sites.) S'il existe un domaine d'application correspondant, la requête y est envoyée à des fins de traitement. Si aucun des serveurs qui exécutent le Service de code en mode bac à sable Microsoft SharePoint Foundation ne possède déjà un domaine d'application pour la solution en bac à sable (sandbox), le gestionnaire d'exécution affecte la requête au moins occupé de ces serveurs. Le serveur crée alors le domaine d'application nécessaire et traite la demande de solution en bac à sable (sandbox). Quel que soit le mode utilisé, local ou d'affinité, le domaine d'application du processus de travail en sandbox reste actif à l'issue du traitement de la requête et est réutilisé en cas de nouvelle demande de cette même solution en bac à sable (sandbox).

Toutes les solutions en bac à sable (sandbox) gérées par un serveur donné s'exécutent dans le même processus de travail en sandbox. Chaque solution en bac à sable (sandbox) obtient son propre domaine d'application au sein du processus commun. Le Service de code en mode bac à sable Microsoft SharePoint Foundation s'exécute dans le compte de la batterie de serveurs.

Exécution de code et accès aux ressources dans le processus de travail en sandbox

Tout le code qui s'exécute dans ce processus de travail en sandbox fait l'objet de contraintes d'exécution et d'accès. Il existe deux systèmes de contraintes : l'un d'eux s'applique uniquement aux appels que le code inclus dans les solutions en bac à sable (sandbox) passe à l'assembly SharePoint Foundation principal, Microsoft.SharePoint.dll. L'autre s'applique à tous les autres appels, y compris les appels passés à tous les autres assemblys SharePoint et aux assemblys .NET Framework. Dans cette rubrique, le premier système est appelé Contraintes du modèle objet côté serveur et le second système est appelé Contraintes générales. (Il existe également diverses contraintes issues du système de rendu des pages fractionnées utilisé dans les solutions en bac à sable (sandbox). Pour plus d'informations, voir la section Système de rendu des pages fractionnées ci-après.)

Les contraintes générales sont imposées par deux mécanismes :

1. Une stratégie CAS hautement restrictive limite considérablement ce que le code peut faire dans un processus de travail en sandbox. Cette stratégie est définie dans le fichier wss_usercode.config dans %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG et est référencée dans le fichier web.config dans %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode. (La modification de ce fichier n'est pas prise en charge.) Parmi les restrictions imposées par la stratégie CAS figurent les suivantes :

   • Le code compris dans le bac à sable (sandbox) ne peut pas appeler de code non managé.

   • Le code compris dans le bac à sable (sandbox) ne peut pas appeler des API de réflexion Microsoft .NET Framework 3.5.

   • Le code compris dans le bac à sable (sandbox) peut uniquement appeler les assemblys .NET Framework 3.5 qui possèdent l'attribut AllowPartiallyTrustedCallersAttribute. Celui-ci bloque l'accès aux 2/3 environ des API .NET Framework 3.5, notamment à System.Printing, à titre d'exemple. Certains assemblys SharePoint également ne possèdent pas l'attribut. Pour obtenir la liste des assemblys .NET Framework qui possèdent et ne possèdent pas cet attribut, voir Assemblys .NET disponibles et non disponibles à partir des solutions en bac à sable (sandbox). Pour obtenir les listes des assemblys SharePoint qui possèdent et ne possèdent pas cet attribut, voir Assemblys SharePoint accessibles et non accessibles à partir de solutions bac à sable (bac à sable).

   Notes

   La stratégie CAS lève une exception pour les stratégies Microsoft Office à nom fort. Celles-ci reçoivent une confiance totale.

   Pour plus d'informations sur cette stratégie CAS et ses implications, voir Restrictions imposées aux solutions en bac à sable (sandbox).

2. Dans un second temps, le processus de travail en sandbox possède un jeton de sécurité à faible privilège.

   • Le jeton refuse au processus le droit d'accès en lecture ou en écriture au système de fichiers.

   • Le jeton refuse au processus le droit d'appeler le réseau. Par conséquent, seules les ressources disponibles sur le serveur qui exécute le processus de travail en sandbox sont accessibles. Une base de données externe, par exemple, n'est pas accessible.

   • Le jeton refuse au processus le droit d'accès en écriture au Registre.

   • Le jeton refuse le droit d'appeler tout assembly absent du Global Assembly Cache (GAC), même s'il possède l'attribut AllowPartiallyTrustedCallersAttribute et serait alors éligible à un appel depuis le processus de travail en sandbox.

N'oubliez pas que ces restrictions ne s'appliquent pas aux appels passés aux API dans l'assembly Microsoft.SharePoint.dll. Ainsi, à titre d'exemple, un appel passé à GetLocalizedString dispose d'un accès en lecture aux fichiers de ressources du système de fichiers et les appels passés à des objets SPList ont accès en lecture et en écriture à la base de données de contenu, quel que soit le serveur qui l'héberge. (En revanche, un fichier ne peut pas être déployé sur un disque dans une solution en bac à sable (sandbox), donc le fichier .resx doit être installé séparément en tant que solution de batterie de serveurs.)

La principale restriction existant dans le système Contraintes du modèle objet côté serveur est que seul un sous-ensemble des API dans l'assembly Microsoft.SharePoint.dll peut être appelé à partir d'une solution en bac à sable (sandbox). Un appel passé à une API interdite lève une exception (laquelle est détectée et signalée à l'utilisateur en tant qu'erreur).

Voici certaines des restrictions existant sur le modèle objet SharePoint accessible :

• La classe SPWebApplication n'est pas disponible. Cela signifie notamment qu'une solution en bac à sable (sandbox) ne peut pas accéder à tout ce qui se trouve à l'extérieur de sa collection de site hôte.

• Presque toutes les classes comprises dans l'espace de noms Microsoft.SharePoint.WebControls ne sont pas disponibles, ce qui signifie que vous êtes essentiellement limité aux contrôles ASP.NET dans les solutions en bac à sable (sandbox).

Pour obtenir la liste complète des classes Microsoft.SharePoint.dll disponibles pour les solutions en bac à sable (sandbox), voir API Microsoft.SharePoint.dll disponibles à partir des solutions en mode bac à sable (sandbox).

L'application de cette restriction s'accompagne de deux versions particulièrement restreintes de l'assembly Microsoft.SharePoint.dll, appelées assemblys shim et localisées dans %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode\assemblies. Ces versions diffèrent de l'assembly Microsoft.SharePoint.dll standard principalement parce qu'elles contiennent uniquement un sous-ensemble des classes et membres de la version standard.

L'un des deux assemblys shim est chargé par le processus de travail en sandbox. L'autre est chargé dans un processus proxy spécial (SPUCWorkerProcessProxy.exe) qui s'exécute en confiance totale et qui est également géré par le Service de code en mode bac à sable Microsoft SharePoint Foundation. L'assembly Microsoft.SharePoint.dll standard est également chargé dans ce processus proxy.

Le principal rôle des deux assemblys shim consiste à filtrer les classes et membres SharePoint interdits. Lorsqu'un appel est passé à l'assembly Microsoft.SharePoint.dll à partir du code du processus de travail en sandbox, il est redirigé vers la version shim de l'assembly. Si l'API appelée ne se trouve pas dans l'assembly shim, alors une exception est levée (laquelle est détectée et signalée à l'utilisateur en tant qu'erreur).

Lorsque la solution en bac à sable (sandbox) appelle une API approuvée contenue dans les assemblys shim, le premier assembly shim la transmet au second dans le processus proxy en confiance totale, qui à son tour, la transmet à l'assembly Microsoft.SharePoint.dll standard. Tous les résultats renvoyés sont retransmis au code appelant d'origine. Cette interaction entre processus est possible par l'intermédiaire de l'accès à distance .NET. Un processus de travail en sandbox et un processus proxy en confiance totale sont toujours lancés de concert et associés l'un à l'autre. Si l'un d'eux se bloque, l'autre s'interrompt également.

Il existe une deuxième restriction dans le système Contraintes du modèle objet côté serveur également imposée par les assembys shim. Certaines API SharePoint peuvent être appelées à partir de solutions en bac à sable (sandbox), mais uniquement avec des restrictions spéciales sur les paramètres qui leur sont transmis. Ce sont les assemblys shim qui imposent ces restrictions d'entrée et qui veillent à lever une exception en cas de violation. Le seul cas dans SharePoint Foundation 2010 concernent les constructeurs SPSite(String) et SPSite(Guid). Ceux-ci sont disponibles pour les solutions en bac à sable (sandbox), mais seuls les URL ou GUID qui se réfèrent à la collection de sites dans laquelle la solution en bac à sable (sandbox) est installée peuvent leur être transmis.

La Figure 1 illustre la manière dont est gérée une requête HTTP lorsqu'elle accède à une solution en bac à sable (sandbox).

Figure 1 : modèle de traitement des requêtes pour les solutions en bac à sable (sandbox)

Les fichiers SPUCHostService.exe, SPUCWorkerProcess.exe et SPUCWorkerProcessProxy.exe se trouvent sous %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode.

Restrictions de l'utilisation des ressources sur les solutions en bac à sable (sandbox)

Les solutions en bac à sable (sandbox) font également l'objet de trois types de restrictions de l'utilisation des ressources, lesquelles peuvent être classées selon (1) le type d'entité auquel la restriction s'applique et (2) le type d'entité sur lequel la pénalité de dépassement de la restriction est imposée.

• Par requête avec requête pénalisée : il existe une limite inconditionnelle pour le délai d'exécution d'une solution en bac à sable (sandbox). Par défaut, cette limite s'élève à 30 secondes. Si une solution en bac à sable (sandbox) dépasse cette limite, la requête (mais pas le processus de travail en sandbox) s'arrête. (Cette limite est configurable, mais uniquement via un code personnalisé par rapport au modèle objet. Les parties concernées du modèle objet ne sont pas disponibles pour les solutions en bac à sable (sandbox), par conséquent aucune solution en bac à sable (sandbox) ne peut modifier cette limite.)

• Par requête avec processus pénalisé : il existe un ensemble de 15 limites supplémentaires sur les ressources applicable aux requêtes. Si une requête dépasse l'une de ces limites, le processus et toutes les solutions en bac à sable (sandbox) qui l'exécutent sont arrêtés.

• Par jour/Par collection de sites avec collection de sites pénalisée : chaque collection de sites fait l'objet d'une configuration d'un nombre maximal de points de ressources quotidiens. Ces points s'accumulent selon un algorithme qui tient compte de l'utilisation des ressources dans les 15 catégories existantes par les solutions en bac à sable (sandbox) installées dans la collection de sites. Lorsqu'une collection de sites dépasse son nombre maximal de points autorisés, toutes les solutions en bac à sable (sandbox) de la collection de sites sont arrêtées et aucune autre ne peut s'exécuter pendant le reste de la journée.

Pour plus d'informations sur les restrictions de ressources imposées aux solutions en bac à sable (sandbox), voir Limites de l'utilisation des ressources sur les solutions en bac à sable (sandbox).

Système de rendu des pages fractionnées

Lorsqu'un ordinateur client demande une page SharePoint qui inclut un composant de solution en bac à sable (sandbox), tel qu'un composant WebPart déployé dans une solution en bac à sable (sandbox), SharePoint restitue plusieurs objets page. L'un d'eux est restitué dans le processus de travail Microsoft ASP.NET (w3wp.exe), les autres sont restitués dans le processus de travail en sandbox. Tous les composants non-sandbox sont restitués sur la page dans le processus de travail ASP.NET, tandis que le premier composant sandbox est restitué sur un objet page dans le processus de travail en sandbox. Lorsque la page du processus de travail en sandbox est entièrement restituée, elle est fusionnée dans l'objet page du processus ASP.NET. S'il existe plusieurs composants sandbox sur la page demandée par l'utilisateur, chacun d'eux est restitué séparément sur son propre objet page dans le processus de travail en sandbox. Chaque objet page de ce type est à son tour fusionné dans l'objet page du processus ASP.NET.

En conséquence, ce système impose d'autres restrictions sur ce qu'il est possible de faire dans une solution en bac à sable (sandbox). Pour plus d'informations sur ces restrictions, voir Restrictions imposées aux solutions en bac à sable (sandbox).

Contournement des restrictions imposées aux solutions en bac à sable (sandbox)

Il existe deux principaux moyens pour une solution en bac à sable (sandbox) de contourner les restrictions habituelles. Le plus importante consiste de loin à utiliser du code côté client pour accéder aux ressources qui ne sont pas disponibles à partir du code côté serveur dans une solution en bac à sable (sandbox). Par exemple, une solution en bac à sable (sandbox) peut inclure une page de site personnalisée contenant du code JavaScript qui permet d'appeler le modèle objet client JavaScript de SharePoint. En outre, une solution en bac à sable (sandbox) peut inclure un composant WebPart qui héberge une application Microsoft Silverlight. Cette dernière application peut appeler le modèle objet client Silverlight de SharePoint. Aucune des restrictions imposées aux solutions en bac à sable (sandbox) ne s'applique au code côté client. Il n'existe aucune restriction d'exécution du code, d'accès aux ressources et d'utilisation des ressources. Pour plus d'informations, voir How to: Extend the Power of a Sandboxed Solution with the SharePoint Client Object Model.

L'architecture des solutions en bac à sable (sandbox) permet également d'utiliser une technique qui permet à une solution en bac à sable (sandbox) d'appeler des opérations personnalisées qui s'exécutent en confiance totale. Cette technique requiert qu'une solution de batterie de serveurs soit développée et que celle-ci inclue une ou plusieurs classes dérivant de SPProxyOperation. Chacune d'elles définit une opération qui s'exécute en confiance totale et qui peut être appelée à partir de solutions en bac à sable (sandbox) via la méthode ExecuteRegisteredProxyOperation. Plus particulièrement, ces opérations proxy en confiance totale s'exécutent dans le même processus proxy (SPUCWorkerProcessProxy.exe) que celui dans lequel l'assembly Microsoft.SharePoint.dll standard s'exécute. Les opérations proxy peuvent retourner des données à la solution en bac à sable (sandbox).

La figure  2 illustre le mode de traitement d'une requête qui accède à une solution en bac à sable (sandbox) lorsque cette solution en bac à sable (sandbox) passe un appel à un proxy en confiance totale.

Figure 2 : modèle de traitement des requêtes lorsqu'une solution en bac à sable (sandbox) appelle un proxy en confiance totale

La description précédente peut donner l'impression qu'avec cette technique, une batterie de serveurs et une solution en bac à sable (sandbox) sont toujours développées ensemble par la même équipe de développement. En fait, la solution de batterie de serveurs contenant les classes d'opération proxy peut être développée plus particulièrement dans le but de fournir certaines opérations à toutes les solutions en bac à sable (sandbox) qui ont besoin de ces services, notamment aux solutions en bac à sable (sandbox) développées par d'autres équipes. Par exemple, étant donné qu'une solution en bac à sable (sandbox) ne peut pas écrire dans les journaux ULS SharePoint, une solution de batterie de serveurs ayant ouvert des opérations de journalisation proxy pour des solutions en bac à sable (sandbox) s'avérerait très utile.

Pour plus d'informations sur le développement et l'appel d'opérations proxy en confiance totale, voir Sandboxed Solutions in Partnership with Full-Trust Proxies in SharePoint 2010 et les autres rubriques du même nœud.

Infrastructure de validation de solution

SharePoint fournit une infrastructure de validation de solution pouvant être utilisée pour développer des validateurs de solution personnalisés comme, par exemple, un validateur qui permet de vérifier si une solution est signée avec un certificat spécifique. Les validateurs d'une collection de sites s'exécutent lorsqu'une solution en bac à sable (sandbox) est activée. L'activation de toute solution non valide est bloquée. Si un validateur est mis à jour ou qu'un nouveau validateur est ajouté, alors chaque solution activée est à nouveau vérifiée par les validateurs lors de sa nouvelle exécution. Les solutions non valides sont désactivées. Pour plus d'informations sur le développement de validateurs personnalisés, voir Solution Validation System.