Partager via


Substitution des vérifications de sécurité

Mise à jour : novembre 2007

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, Deny 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.

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, Deny ou PermitOnly. Si un appelant utilise plusieurs Assert, Deny 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, Deny 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.

Remarque :

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, Deny 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, Deny et PermitOnly.

Remarque :

Si vous effectuez une substitution (Deny, 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é. Par exemple, si vous refusez une autorisation, P, vous devez reprendre cette autorisation avant de pouvoir refuser une autre autorisation, Q, dans la même méthode.

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

CodeAccessPermission.RevertAll

Provoque la suppression et la désactivation de toutes les précédentes substitutions pour le frame en cours.

CodeAccessPermission.RevertAssert

Provoque la suppression et la désactivation du Assert précédent pour le frame en cours.

CodeAccessPermission.RevertDeny

Provoque la suppression et la désactivation du précédent pour le frame en cours.

CodeAccessPermission.RevertPermitOnly

Provoque la suppression et la désactivation du précédent pour le frame en cours.

Voir aussi

Concepts

Écriture des bibliothèques de classes sécurisées

Référence

Utilisation de la méthode Assert

Utilisation de la méthode Deny

Utilisation de la méthode PermitOnly

Autres ressources

Sécurité d'accès du code