Sécurité et approbation
Le .NET Framework a un modèle de sécurité qui traite différemment les applications en fonction de leur origine. Les exécutables et assemblys provenant de l’ordinateur d’un utilisateur s’exécutent généralement avec une confiance totale ; les mêmes exécutables et assemblys s’exécutent généralement sur Internet avec une approbation partielle. Il s’agit d’empêcher le code malveillant de lire ou de modifier des informations auxquelles il ne doit pas avoir accès, telles que les fichiers locaux, les éléments du Presse-papiers et d’autres ressources. Si un exécutable appelle un assembly, qui à son tour appelle un autre assembly qui nécessite un certain niveau de confiance, le niveau de confiance le plus bas de tous les composants de la chaîne est appliqué. Toutefois, un administrateur sur une machine peut définir des autorisations spécifiques qui remplacent les autorisations par défaut.
Une vue d’ensemble du modèle de sécurité est donnée dans Secure, Light-Weight Client-Side Controls, et vous pouvez obtenir plus d’informations sur le modèle de sécurité dans Code Access Security in Practice. Vous trouverez une bonne vue d’ensemble de la sécurité des bibliothèques (ce qui est particulièrement important pour les objets UserControl d’une page Web) dans Utilisation de bibliothèques à partir de code partiellement approuvé, et d’autres informations de sécurité sur les contrôles managés sont disponibles dans Écriture de contrôles managés sécurisés.
Autorisations
La plupart des objets managés et membres de l’API Tablet PC Technologies ont deux exigences :
- L’exécution est toujours requise.
- FullTrust est requis lorsque l’action de sécurité HéritageDemand a lieu. Cela signifie qu’une confiance totale est requise lorsqu’une classe dérivée hérite d’une classe ou remplace une méthode du Kit de développement logiciel (SDK) Tablet PC.
Le tableau suivant répertorie les classes et les membres qui nécessitent des autorisations supplémentaires. Les autorisations d’une classe donnée s’appliquent également à tous ses membres qui ne figurent pas dans cette table.
Notes
Il est généralement préférable d’utiliser un contrôle plutôt qu’un handle (IntPtr) pour les constructeurs, car les contrôles nécessitent moins d’autorisations. De même, il est préférable d’utiliser un objet Graphics plutôt qu’un handle pour Renderer.Draw, Renderer.InkSpaceToPixel et Renderer.PixelToInkSpace.
Notes
Les propriétés InkCollector.Handle et InkOverlay.Handle ne nécessitent pas l’autorisation SecurityPermissionFlag.UnmanagedCode si le handle concerne un contrôle Windows Forms, mais elles le font pour d’autres fenêtres.
Notes
Pour la classe PenInputPanel , les méthodes et propriétés suivantes nécessitent SecurityPermissionFlag.AllFlags : PenInputPanel(IntPtr), AttachedEditWindow, Busy, CommitPendingInput, CurrentPanel, DefaultPanel, EnableTsf, Factoid, Height, HorizontalOffset, InputFailed, Left, MoveTo, PanelChanged, PanelMoving, Refresh , Top, VerticalOffset, Visible, VisibleChanged et Width.
Autres considérations
Voici d’autres considérations connues en matière de sécurité :
- Microsoft Internet Explorer 6 ou version ultérieure est nécessaire pour que les contrôles Web fonctionnent correctement. Avec Internet Explorer 5.5, seuls les contrôles managés initiaux se chargent ; vous ne pouvez pas charger dynamiquement des contrôles supplémentaires au moment de l’exécution.
- Si vous utilisez Windows XP Service Pack 2 (SP2) et CLR1.0, les contrôles Web dans Internet Explorer nécessitent l’ajout du site en tant que site approuvé, même s’ils se trouvent dans la zone Intranet. Toutefois, lorsque vous le faites, ils ne s’exécuteront plus dans la zone Site approuvé, bien qu’ils s’exécutent dans la zone Intranet. Ce problème est résolu avec CLR1.1.