Restrictions imposées aux solutions en bac à sable (sandbox)
Cette rubrique décrit les restrictions imposées au code qui s’exécute dans des solutions en bac à sable (sandbox).
Dernière modification : mercredi 13 avril 2011
S’applique à : SharePoint Foundation 2010
Dans cet article
Trois processus de travail
Jeton de sécurité à faible privilège pour le processus de travail bac à sable
Stratégie de sécurité d’accès du code restrictive pour le processus de travail bac à sable
Versions spéciales de l’assembly Microsoft.SharePoint.dll
Système d’affichage de pages fractionnées
Limitations de l’utilisation des ressources
Validation de solutions relative aux batteries
Blocage de solutions relatif aux batteries
Blocage de classes relatif aux batteries
Limitations diverses
Disponible dans SharePoint Online
Les différentes restrictions peuvent être réparties utilement dans les catégories suivantes, selon les mécanismes qui imposent les restrictions.
Trois processus de travail
Jeton de sécurité à faible privilège pour le processus de travail bac à sable
Stratégie de sécurité d’accès du code restrictive pour le processus de travail bac à sable
Versions spéciales de l’assembly Microsoft.SharePoint.dll
Système d’affichage de pages fractionnées
Limitations de l’utilisation des ressources
Validation de solutions relative aux batteries
Blocage de solutions relatif aux batteries
Blocage de classes relatif aux batteries
Limitations diverses
Trois processus de travail
Comme expliqué dans Architecture des solutions en bac à sable (sandbox), le code bac à sable (sandbox) s’exécute dans un processus de travail distinct du processus de travail Microsoft ASP.NET standard et effectue des appels à un troisième processus proxy de confiance totale. Cette structure impose des restrictions aux solutions en bac à sable (sandbox), indépendamment des autorisations du processus de travail bac à sable.
Restriction |
Implications et remarques |
|---|---|
Le gestionnaire WebResources.axd, qui s’exécute dans le processus de travail ASP.NET, ne peut pas accéder aux ressources incorporées dans des assemblys du processus de travail bac à sable. |
Les assemblys dans les solutions en bac à sable (sandbox) ne peuvent pas utiliser de ressources incorporées. |
Jeton de sécurité à faible privilège pour le processus de travail bac à sable
Le processus de travail bac à sable reçoit un jeton de sécurité à faible privilège (celui-ci étant différent du jeton de sécurité utilisateur). Le jeton impose les restrictions suivantes.
Restriction |
Implications et remarques |
|---|---|
Le code dans le processus ne peut pas lire le système de fichiers ni écrire dans celui-ci (mais il peut lire et exécuter des assemblys dans le Global Assembly Cache). |
1. Les pages d’application, les pages mobiles et les contrôles utilisateur (fichiers .ascx) ne peuvent pas être déployés dans une solution en bac à sable (sandbox). Idem pour les composants Visual Web Part, car ceux-ci incluent un contrôle utilisateur. Les contrôles de délégué implémentés en tant que contrôles utilisateur ne peuvent pas non plus figurer dans une solution en bac à sable (sandbox). Cependant, d’autres types de fichiers peuvent être déployés dans la base de données de contenu et ainsi être inclus dans des solutions en bac à sable (sandbox). Il s’agit notamment des fichiers de script, des fichiers images et des assemblys. (Pour plus d’informations, voir How to: Create and Deploy a non-RESX Resources in a Sandboxed Solution et Où les assemblys sont-ils déployés dans les solutions en bac à sable (sandbox) ?). .gif "Remarque") Remarque
La galerie ExtensionsMicrosoft Visual Studio possède une extension qui vous permet d’ajouter un composant Visual Web Part à un projet de solution en bac à sable (sandbox). Vous pouvez ainsi utiliser le concepteur visuel ; toutefois, le contrôle utilisateur (fichier ASCX) est compilé avec le code-behind dans l’assembly et n’est pas déployé avec la solution. Par conséquent, les avantages du déploiement d’ASCX ne sont pas mis en avant par cette extension.
2. Les définitions de site requérant un fichier WebTemp*.xml, celles-ci ne peuvent pas être déployées dans une solution en bac à sable (sandbox). Cependant, vous pouvez déployer des types de sites personnalisés dans des solutions en bac à sable (sandbox) en utilisant un élément WebTemplate à la place d’un fichier WebTemp*.xml. Pour plus d’informations, voir How to: Deploy a Web Template in a Sandboxed Solution. 3. Les fichiers de ressources (.resx) ne peuvent pas être déployés dans une solution en bac à sable (sandbox), mais il est possible de localiser des solutions en bac à sable (sandbox) sans déployer des fichiers de ressources dans le système de fichiers serveur. Pour plus d’informations, voir Localisation de solutions en mode bac à sable (sandbox). 4. Les fichiers Web.config ne peuvent ni être déployés avec une solution en bac à sable (sandbox), ni être modifiés. La même restriction s’applique aux fichiers .config supplémentaires. Pour plus d’informations, voir Comment : créer un fichier .config supplémentaire. Et du fait de l’indisponibilité de la classe SPWebConfigModification (voir plus loin dans cette rubrique), vous ne pouvez pas modifier les paramètres web.config dans une solution en bac à sable (sandbox). |
Le code dans le processus ne peut pas appeler le réseau. |
Seules les ressources qui sont disponibles sur le serveur exécutant le processus de travail bac à sable sont accessibles. Une base de données externe, par exemple, n’est pas accessible. Cela signifie donc que vous ne pouvez pas déployer de modèle BCS dans une solution en bac à sable (sandbox). |
Le code dans le processus ne peut pas écrire dans le Registre. |
|
Le code dans le processus ne peut appeler d’assemblys qui ne sont pas déployés dans le Global Assembly Cache. (Les assemblys qui sont déployés dans le cadre de la solution en bac à sable (sandbox) constituent une exception à cette règle. Pour plus d’informations, voir Où les assemblys sont-ils déployés dans les solutions en bac à sable (sandbox) ?) |
Les assemblys Microsoft SharePoint Foundation et SharePoint Server qui ne sont pas installés dans le Global Assembly Cache ne peuvent pas être appelés par du code qui s’exécute dans le processus de travail bac à sable. Par exemple, l’assembly Microsoft.SharePoint.UserCode.dll ne peut pas être appelé. |
Important
Le jeton de sécurité du processus de travail bac à sable ne s’applique pas aux appels effectués aux API dans l’assembly Microsoft.SharePoint.dll, car ces API s’exécutent dans un processus de confiance totale distinct. Par exemple, le fait que le jeton de sécurité pour le processus de travail bac à sable bloque l’accès aux bases de données externes n’empêche pas une solution en bac à sable (sandbox) d’accéder à une liste externe sur un site Web SharePoint. De même, une liste SharePoint standard est accessible lorsque la base de données de contenu se trouve sur un serveur différent de celui qui gère la solution en bac à sable (sandbox). Pour plus d’informations, voir Architecture des solutions en bac à sable (sandbox).
Stratégie de sécurité d’accès du code restrictive pour le processus de travail bac à sable
La stratégie de sécurité d’accès du code (CAS) pour le processus de travail d’une solution en bac à sable (sandbox) est définie dans le fichier %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG\wss_usercode.config, et est référencée dans le fichier web.config situé à l’emplacement %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\UserCode. Cette stratégie accorde uniquement les autorisations répertoriées dans le tableau suivant.
Autorisation accordée |
Remarques |
|---|---|
Toutefois, les classes du modèle objet ne sont pas toutes accessibles à partir du code bac à sable. Voir la section Versions spéciales de l’assembly Microsoft.SharePoint.dll plus loin dans cette rubrique. |
|
Le niveau d’autorisation minimal permet l’exécution des ressources, mais ne confère pas l’accès en lecture/écriture aux ressources ni toute autre autorisation vis-à-vis de celles-ci. Les appels au code non managé ne sont pas autorisés. |
Le tableau suivant regroupe une sélection des autorisations qui ne sont pas accordées par la stratégie CAS.
Autorisation refusée |
Remarques |
|---|---|
En cas d’absence de cette autorisation, le code bac à sable se voit refuser l’accès en lecture/écriture au système de fichiers. Ce même droit est également refusé par le jeton de sécurité du processus de travail bac à sable. |
|
En cas d’absence de cette autorisation, le code bac à sable se voit refuser l’accès aux API Reflection ASP.NET et, par conséquent, aux classes et membres non publics du code managé. |
|
En cas d’absence de cette autorisation, le code bac à sable se voit refuser l’accès au Registre. Ce même droit est également refusé par le jeton de sécurité du processus de travail bac à sable. |
|
En cas d’absence de cette autorisation, le code bac à sable se voit refuser l’accès au code non managé et aux sous-systèmes de thread et de domaine d’application. L’absence de cette autorisation signifie également qu’il est plus difficile pour du code non autorisé de se soustraire aux restrictions de la stratégie CAS. |
|
En cas d’absence de cette autorisation, le code dans la solution en bac à sable (sandbox) ne peut pas accéder aux bases de données SharePoint. Le code qui appelle l’assembly Microsoft.SharePoint.dll constitue une exception à cette règle et peut donc accéder aux bases de données, si tant est que l’appel est autorisé par les versions spéciales de cet assembly. Pour plus d’informations sur ces assemblys spéciaux et le rôle qu’ils jouent, voir Versions spéciales de l’assembly Microsoft.SharePoint.dll plus loin dans cette rubrique. .gif "Remarque importante") Important
Bien souvent, les appels aux API dans des assemblys SharePoint Foundation et SharePoint Serverautres que Microsoft.SharePoint.dll échouent en raison de cette restriction, même si l’assembly figure dans le Global Assembly Cache et qu’il possède l’attribut AllowPartiallyTrustedCallers. Seul l’assembly Microsoft.SharePoint.dll possède les versions spéciales qui lui permettent de recevoir des appels pour échapper au processus de travail et s’exécuter dans un processus de confiance totale.
|
|
Pour plus d’informations sur les stratégies CAS, voir Utilisation de la sécurité d’accès au code avec ASP.NET, Conseils de sécurité pour .NET Framework 2.0 (éventuellement en anglais) et La sécurité d’accès du code en pratique.
Important
La stratégie CAS du processus de travail bac à sable ne s’applique pas aux appels effectués aux API dans l’assembly Microsoft.SharePoint.dll, car ces API s’exécutent dans un processus de confiance totale distinct. Par exemple, un appel à GetLocalizedString peut lire des fichiers de ressources dans le système de fichiers. Pour plus d’informations, voir Architecture des solutions en bac à sable (sandbox).
Notes
La stratégie CAS fait une exception pour les assemblys Microsoft Office avec un nom fort. Ceux-ci se voient accorder une confiance totale.
Impossible d’appeler les assemblys sans l’attribut AllowPartiallyTrustedCallers
Si une stratégie CAS n’accorde pas une confiance totale au code dans le processus de travail bac à sable, le code régi par la stratégie CAS peut uniquement appeler des assemblys avec l’attribut AllowPartiallyTrustedCallersAttribute. Cet effet secondaire notable se produit indépendamment des détails de la stratégie. Ainsi, le code dans le processus de travail bac à sable ne peut appeler aucun assembly, y compris les assemblys Microsoft .NET Framework, SharePoint Foundation et SharePoint Server qui ne possèdent pas cet attribut. Le tableau suivant recense quelques implications de cette restriction.
Assembly sans l’attribut AllowPartiallyTrustedCallers |
Implications et remarques |
|---|---|
Microsoft.SharePoint.WorkflowActions |
Les flux de travail codés ne peuvent pas être déployés dans une solution en bac à sable (sandbox), car de tels flux nécessitent un accès aux classes dans cet assembly. (Les flux de travail « Aucun code », créés dans Microsoft SharePoint Designer et éventuellement modifiés dans Visual Studio, peuvent être déployés dans des solutions en bac à sable (sandbox).) |
Pour obtenir les listes répertoriant les assemblys .NET Framework et SharePoint disponibles, et ceux qui ne le sont pas, voir Assemblys .NET disponibles et non disponibles à partir des solutions en bac à sable (sandbox) et Assemblys SharePoint accessibles et non accessibles à partir de solutions bac à sable (bac à sable).
Versions spéciales de l’assembly Microsoft.SharePoint.dll
Comme expliqué dans Architecture des solutions en bac à sable (sandbox), les appels du code dans le processus de travail bac à sable à l’assembly Microsoft.SharePoint.dll sont redirigés vers une version spéciale de cet assembly. La version spéciale est par certains côtés moins privilégiée que d’autres assemblys dans le processus de travail bac à sable, et par d’autres plus privilégiée.
La restriction la plus significative réside dans le fait que la version spéciale contient uniquement un sous-ensemble des classes et des méthodes de l’assembly standard. Une exception est levée lorsque le code appelle une API qui n’est pas incluse dans la version spéciale de l’assembly. Le tableau suivant répertorie quelques-uns des API qui ne sont pas inclus dans la version spéciale de l’assembly. Pour obtenir la liste complète des classes qui sont incluses, voir API Microsoft.SharePoint.dll disponibles à partir des solutions en mode bac à sable (sandbox).
API bloquée |
Implications et remarques |
|---|---|
La majeure partie de l’espace de noms Microsoft.SharePoint.Administration, y compris les classes SPWebApplication et SPFarm. |
1. Les fonctionnalités d’une solution en bac à sable (sandbox) ne peuvent pas être déployées dans une étendue au niveau d’une batterie ou d’une application Web. Ainsi, le type de fonctionnalité pouvant être déployée uniquement dans ces étendues ne peut en aucun cas être déployé dans une solution en bac à sable (sandbox). Par exemple, un modèle de connectivité de données métiers ne peut pas être déployé dans une solution en bac à sable (sandbox). 2. Pratiquement aucun objet et aucune ressource au-delà du niveau de la collection de sites dans le modèle objet ne sont accessibles aux solutions en bac à sable (sandbox). 3. Les convertisseurs de documents, qui sont inscrits auprès de l’application Web, ne peuvent pas être inscrit dans une solution en bac à sable (sandbox). |
Toutes les classes de contrôle dans l’espace de noms Microsoft.SharePoint.WebControls. |
Le code dans les solutions bac à sable est limité aux contrôles ASP.NET. |
Classe WebPartMobileAdapter. |
Le code bac à sable ne peut pas contenir d’adaptateur mobile WebPart. |
Les solutions bac à sable peuvent uniquement inclure des composants WebPart dérivés de la classe ASP.NETSystem.Web.UI.WebControls.WebParts.WebPart. |
|
Les travaux du minuteur ne peuvent pas être inclus dans les solutions en bac à sable (sandbox). |
|
Vous ne pouvez pas modifier par programme les paramètres web.config avec une solution en bac à sable (sandbox). Et du fait que les solutions en bac à sable (sandbox) ne peuvent pas lire le système de fichiers du serveur ni écrire dans celui-ci (voir plus haut dans cette rubrique), vous ne pouvez pas modifier les paramètres web.config dans une solution en bac à sable (sandbox). |
|
Les méthodes dans une solution en bac à sable (sandbox) ne peuvent pas être configurées de manière à s’exécuter avec les privilèges élevés de l’identité de l’utilisateur sous laquelle le pool d’applications s’exécute. |
Par ailleurs, même lorsqu’une méthode est incluse dans la version spéciale de l’assembly, elle peut imposer des restrictions supplémentaires aux paramètres passés à l’API. Par exemple, les constructeurs SPSite(String) et SPSite(Guid) sont accessibles aux solutions en bac à sable (sandbox), mais seuls les URL ou les GUID qui font référence à la collection de sites dans laquelle la solution en bac à sable (sandbox) est installée peuvent leur être passés. De cette façon, une solution en bac à sable (sandbox) n’a pas accès aux sites Web, listes ou autres ressources en dehors de la collection de sites sur laquelle elle a été installée.
Il est important de noter que les appels à Microsoft.SharePoint.dll qui sont autorisés par l’opérateur de contrôle d’appels de l’assembly spécial disposent de plus de privilèges que les appels aux autres assemblys. Ainsi, l’API qui est appelée ne s’exécute pas dans le processus de travail bac à sable restreint. Au lieu de cela, l’appel est transféré à un processus de proxy de confiance totale dans lequel l’API s’exécute sans restriction. Cela signifie que de tels appels peuvent effectuer des opérations, comme l’accès aux bases de données SharePoint, qui ne peuvent pas être accomplies par des appels à d’autres assemblys, pas même à d’autres assemblys SharePoint.
Système d’affichage de pages fractionnées
Comme expliqué dans Architecture des solutions en bac à sable (sandbox), lorsqu’un ordinateur client demande une page SharePoint qui inclut un composant d’une solution en bac à sable (sandbox), par exemple un composant WebPart déployé dans une solution en bac à sable (sandbox), SharePoint affiche plusieurs objets de page. L’un est affiché dans le processus de travail ASP.NET (w3wp.exe) et les autres dans le processus de travail bac à sable. Tous les composants qui ne sont pas des composants bac à sable sont affichés sur la page dans le processus de travail ASP.NET, alors que le premier composant bac à sable est affiché sur un objet de page dans le processus de travail bac à sable. Lorsque la page dans le processus de travail bac à sable est entièrement affichée, elle est fusionnée dans l’objet de page du le processus ASP.NET. Si plusieurs composants bac à sable figurent sur la page demandée par l’utilisateur, chaque composant est affiché séparément sur son propre objet de page dans le processus de travail bac à sable. Chaque objet de page de la sorte est à son tour fusionné dans l’objet de page du processus ASP.NET.
Ce système implique qu’un composant WebPart qui est déployé dans une solution en bac à sable (sandbox) ne peut pas être un composant WebPart fournisseur ni un composant WebPart consommateur dans une connexion WebPart. Cela est dû au fait que chaque composant WebPart bac à sable s’affiche entièrement dans son propre objet de page. (Les connexions WebPart sur plusieurs pages sont possibles avec les composants WebPart qui dérivent de classe Microsoft.SharePoint.WebPartPages.WebPart, mais cette classe est bloquée par le shim Microsoft.SharePoint.dll [voir plus haut dans cette rubrique]. Seuls les composants WebPart dérivés de la classe System.Web.UI.WebControls.WebParts.WebPart sont pris en charge dans les solutions en bac à sable (sandbox), et ils n’autorisent pas les connexions WebPart sur plusieurs pages.)
Une autre conséquence du système d’affichage de pages fractionnées est le fait que certains types ASP.NET ne peuvent pas être fusionnés à partir d’un objet de page du processus bac à sable dans la page finale qui est retournée. Cela signifie qu’il est inutile que le code dans une solution en bac à sable (sandbox) écrive dans les propriétés de l’objet ASP.NETPage (ou de ses objets enfants), celui-ci contenant des objets de type non fusionnable. Le tableau suivant identifie quelques-uns de ces types.
Type non fusionnable |
Implications et remarques |
|---|---|
Le code bac à sable ne doit pas écrire dans la propriété ClientScript. Toutefois, le script côté client peut être inscrit auprès de la page d’autres manières. Par exemple, vous pouvez incorporer le script en tant que contrôle LiteralControl et l’ajouter à une collection de contrôles dans une méthode CreateChildControls(). |
|
Le code bac à sable ne doit pas ajouter un objet ScriptManager à la collection de contrôles de tout objet. |
|
Le code bac à sable ne doit pas écrire dans la propriété Cache. |
|
Le code bac à sable ne doit pas écrire dans la propriété Master. Toutefois, il peut pointer la page vers une page maître différente en écrivant dans la propriété MasterPageFile. |
|
Le code bac à sable ne doit pas écrire dans la propriété Session. |
Limitations de l’utilisation des ressources
Les solutions bac à sable ne peuvent pas surutiliser les ressources système. Cette spécification est mise en œuvre par l’infrastructure d’analyse de ressource SharePoint Foundation.
Pour plus d’informations, voir Limites de l'utilisation des ressources sur les solutions en bac à sable (sandbox) et Architecture des solutions en bac à sable (sandbox).
Validation de solutions relative aux batteries
Comme décrit dans Solution Validation System, les administrateurs de batterie peuvent imposer la validation des solutions personnalisées aux solutions en bac à sable (sandbox). En fait, ils peuvent imposer des restrictions supplémentaires quant aux opérations effectuées par une solution en bac à sable (sandbox). Vous devez vous renseigner auprès des administrateurs de batterie pour déterminer les validateurs qu’ils utilisent.
Blocage de solutions relatif aux batteries
Les administrateurs de batterie peuvent placer n’importe quelle solution en bac à sable (sandbox) dans une liste de solutions bloquées dans l’Administration centrale.
Blocage de classes relatif aux batteries
Les administrateurs de batterie peuvent exécuter du code personnalisé qui empêche des classes managées spécifiées d’être appelées dans le processus de travail bac à sable. Pour plus d’informations, voir SPRestrictedObjectModel.
Limitations diverses
Le tableau suivant identifie les restrictions imposées aux solutions en bac à sable (sandbox) qui ne figurent pas dans les autres sections de cette rubrique.
Restriction |
Implications et remarques |
|---|---|
Vous ne pouvez pas déployer d’élément HideCustomAction dans une solution en bac à sable (sandbox). |
Vous ne pouvez pas utiliser de solution en bac à sable (sandbox) pour masquer un élément de menu, un bouton du Ruban ou un lien dans une page d’administration, telle que la page Paramètres du site. Toutefois, vous pouvez ajouter une nouvelle action personnalisée à l’un de ces éléments au moyen d’une solution en bac à sable (sandbox). Pour plus d’informations, voir Qu'est-ce qui peut être implémenté dans une solution en bac à sable (sandbox) ?. |
Vous ne pouvez pas déployer d’élément CustomActionGroup dans une solution en bac à sable (sandbox). |
Bien que vous puissiez ajouter une nouvelle action personnalisée dans une solution en bac à sable (sandbox), vous ne pouvez pas créer un nouveau groupe d’actions pour vos actions personnalisées. Pour plus d’informations, voir Qu'est-ce qui peut être implémenté dans une solution en bac à sable (sandbox) ?. |
Vous ne pouvez pas inscrire de candidat de contrôle pour un contrôle de délégué (élément Control) dans une solution en bac à sable (sandbox). |
Voir aussi
Concepts
Qu'est-ce qui peut être implémenté dans une solution en bac à sable (sandbox) ?
Meilleures pratiques en matière de développement de solutions bac à sable (sandbox)