Sécurité déclarative utilisée avec la portée de la classe et du membre
Mise à jour : novembre 2007
La sécurité déclarative peut s'effectuer sur des classes, des membres et des classes imbriquées. Cette section présente les règles utilisées pour évaluer la sécurité déclarative lorsqu'elle est appliquée à plusieurs niveaux de la même classe.
Classes, membres et la sécurité déclarative
Lorsqu'une sécurité déclarative est utilisée pour la même action de sécurité à la fois au niveau de la classe et au niveau de la méthode, elle est appliquée d'après le tableau suivant.
Action de sécurité |
Comportement des versions 1.0 et 1.1 du .NET Framework |
Comportement de la version 2.0 du .NET Framework |
---|---|---|
Demande |
Les attributs au niveau de la méthode substituent les attributs au niveau de la classe. (Si une demande déclarative est placée au niveau de la méthode, une demande déclarative au niveau de la classe sera ignorée.) |
Les attributs au niveau de la méthode et les attributs au niveau de la classe sont réunis ensemble dans un même jeu d'autorisations. |
Demande de liaison |
Les attributs au niveau de la méthode et les attributs au niveau de la classe sont réunis. |
Aucune modification du comportement. |
Demande d'héritage |
Les attributs au niveau de la classe requièrent l'autorisation spécifiée pour dériver de la classe. Les attributs au niveau de la méthode requièrent l'autorisation spécifiée pour substituer la méthode dans une classe dérivée. Comme les demandes d'héritage ont des significations différentes pour les classes et les méthodes, les déclarations peuvent s'appliquer aussi bien au niveau de la classe qu'au niveau de la méthode de façon indépendante. |
Aucune modification du comportement. |
Assert |
Les attributs au niveau de la méthode substituent les attributs au niveau de la classe. |
Les attributs au niveau de la méthode et les attributs au niveau de la classe sont réunis ensemble dans un même jeu d'autorisations. |
Deny |
Les attributs au niveau de la méthode substituent les attributs au niveau de la classe. |
Les attributs au niveau de la méthode et les attributs au niveau de la classe sont réunis ensemble dans un même jeu d'autorisations. |
PermitOnly |
Les attributs au niveau de la méthode substituent les attributs au niveau de la classe. |
Les attributs au niveau de la méthode et les attributs au niveau de la classe se recoupent ensemble dans un même jeu d'autorisations. |
Si les actions de sécurité sont différentes (par exemple, une demande au niveau de la classe avec une assertion au niveau de la méthode), il n'y aucune interaction et les deux sont évaluées.
Classes imbriquées et sécurité déclarative
Lorsque vous appliquez la sécurité déclarative aux classes, elle ne se propage à aucune classe ou méthode imbriquée des classes imbriquées. Inversement, lorsque vous appliquez la sécurité déclarative aux classes ou méthodes imbriquées d'une classe imbriquée, elle ne se propage pas non plus aux classes parentes. Vous devez appliquer la sécurité déclarative aux classes imbriquées comme s'il s'agissait de classes séparées.
L'exemple suivant illustre une autorisation hypothétique exigée au niveau de la classe d'une classe nommée Main. Dans cette classe, une classe imbriquée nommée Nested est définie. Dans cet exemple, la demande ne s'applique pas à la classe imbriquée.
<SomePermissionAttribute(SecurityAction.Demand, Unrestricted:=True)> _
Public Class Main
' This nested class is not influenced by the demand.
Public Class Nested
' This method is not influenced by the demand.
Public Sub MyMethod()
End Sub
End Class
End Class
[SomePermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
class Main
{
// This nested class is not influenced by the demand.
class Nested
{
// This method is not influenced by the demand.
public void MyMethod()
{
}
}
}