Sécurité déclarative utilisée avec la portée de la classe et du membre
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.
Important
Dans le .NET Framework 4, la prise en charge du runtime a été supprimée afin d'appliquer les demandes d'autorisation Deny, RequestMinimum, RequestOptional et RequestRefuse.Ces demandes ne devraient pas être utilisées dans le code qui est basé sur le .NET Framework 4 ou version ultérieure.Pour plus d'informations sur cette modification et d'autres modifications, consultez Modifications de sécurité dans le .NET Framework .
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 de la version 2.0 du .NET Framework |
Comportement de .NET Framework 4 |
|---|---|---|
Demande |
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. |
Aucune modification du comportement. |
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 et les attributs au niveau de la classe sont réunis ensemble dans un même jeu d'autorisations. |
Aucune modification du comportement. |
Refuser |
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. |
Obsolète dans .NET Framework 4. |
PermitOnly |
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. |
Aucune modification du comportement. |
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()
{
}
}
}