Substitution des vérifications de sécurité
Une vérification de sécurité examine normalement chaque appelant dans la pile des appels pour s'assurer que l'autorisation spécifiée lui a été octroyée. Vous pouvez cependant substituer le résultat des vérifications de sécurité en appelant Assert ou PermitOnly sur un objet d'autorisation individuel ou un objet de jeu d'autorisations. En fonction des méthodes que vous appelez, vous pouvez provoquer le succès ou l'échec de la vérification de sécurité, même s'il est probable que les autorisations de tous les appelants de la pile n'aient pas été vérifiées.
Important
Dans le .NET Framework 4, la prise en charge du runtime a été supprimée afin d'appliquer les demandes d'autorisation Deny et RevertDeny.Ces demandes ne doivent 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 .
Chaque fois qu'une méthode en appelle une autre, un nouveau frame est généré sur la pile des appels afin de stocker les informations concernant la méthode appelée. (L'utilisation des constructeurs et l'accès aux propriétés sont considérés comme des appels de méthodes dans ce contexte.) Chaque frame de pile comprend des informations concernant les appels de la méthode à Assert ou PermitOnly. Si un appelant utilise plusieurs Assert ou PermitOnly dans le même appel à une méthode, le runtime applique les règles de traitement suivantes, ce qui peut affecter les comportements de substitution :
Si, pendant le parcours de pile, le runtime découvre plusieurs substitutions du même type (c'est-à-dire deux appels à Assert) dans un frame de pile, la deuxième substitution provoque la levée d'une exception.
Lorsque différentes substitutions sont présentes dans le même frame de pile, le runtime traite ces substitutions dans l'ordre suivant : PermitOnly puis Assert.
Pour remplacer une substitution, appelez d'abord la méthode de rétablissement appropriée (par exemple RevertAssert) puis appliquez la nouvelle substitution.
Notes
Les substitutions de parcours de pile ne doivent jamais être faites dans un constructeur de classe car il n'est pas garanti que le code du constructeur de classe s'exécute à un point particulier ou dans un contexte particulier.Étant donné que l'état de la pile des appels dans un constructeur de classe n'est pas bien défini, les substitutions de parcours de pile placées dans des constructeurs peuvent produire des résultats imprévus et indésirables.
Les développeurs d'applications n'ont généralement pas besoin d'utiliser Assert ou PermitOnly et les développeurs de bibliothèques de classes et de composants ont rarement besoin de les utiliser. Toutefois, les substitutions de sécurité sont appropriées dans certaines situations décrites dans les rubriques Assert et PermitOnly.
Notes
Si vous effectuez une substitution (Assert ou PermitOnly), vous devez reprendre l'autorisation avant d'effectuer le même type de substitution dans le même frame de pile (c'est-à-dire la méthode).Sinon, SecurityException est levé.
Utilisez une des méthodes statiques répertoriées dans le tableau ci-dessous afin de reprendre une substitution.
Méthode |
Action de la méthode |
|---|---|
Provoque la suppression et la désactivation de toutes les précédentes substitutions pour le frame en cours. |
|
Provoque la suppression et la désactivation du Assert précédent pour le frame en cours. |
|
Provoque la suppression et la désactivation du précédent pour le frame en cours. |
Voir aussi
Référence
Utilisation de la méthode d'assertion
Utilisation de la méthode de PermitOnly
Concepts
Écriture des bibliothèques de classes sécurisées