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, 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.
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, 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.
Notes
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). Dans le cas contraire, une exception SecurityException est levée. 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 |
|---|---|
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. |
|
Provoque la suppression et la désactivation du précédent pour le frame en cours. |
Voir aussi
Référence
Using the Assert Method
Using the Deny Method
Using the PermitOnly Method
Concepts
Écriture des bibliothèques de classes sécurisées