Demandes de sécurité

Pour s'assurer que seuls les appelants ayant reçu une autorisation spécifiée peuvent appeler votre code, vous pouvez demander de manière déclarative ou impérative que les appelants de votre code aient une autorisation ou un jeu d'autorisations spécifique. Une demande conduit le runtime à effectuer une vérification de sécurité afin d'appliquer les restrictions sur le code appelant. Pendant une vérification de sécurité, le runtime parcourt la pile des appels, en examinant les autorisations de chaque appelant dans la pile et en déterminant si l'autorisation demandée a été octroyée à chaque appelant. Si un appelant n'ayant pas l'autorisation sollicitée est trouvé, la vérification de sécurité échoue et une SecurityException est levée. Les seules demandes qui n'entraînent pas de parcours de pile sont les demandes de liaison, qui ne vérifient que l'appelant immédiat.

Vous pouvez provoquer une vérification de sécurité chaque fois qu'une méthode particulière est appelée ou avant qu'un bloc particulier de code soit exécuté. Si vous souhaitez que la vérification de sécurité ait lieu lorsqu'un membre d'une classe particulière est appelé, vous pouvez placer une demande avant la classe de sorte qu'elle s'applique à chaque membre de la classe. La suite de cette rubrique explique comment effectuer des demandes de sécurité, quand le moment est opportun et quel type de demande de sécurité privilégier.

Si vous écrivez une bibliothèque qui accède directement à une ressource protégée et si cet accès est exposé à l'appelant, vous devez faire une demande de sécurité dans la bibliothèque pour vous assurer que tous les appelants dans la pile des appels ont l'autorisation d'accéder à cette ressource. Vos demandes peuvent être déclaratives ou impératives. Notez que les demandes 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 demandes appliquées à des constructeurs de classe peuvent produire des résultats imprévus et indésirables.

Nous vous conseillons de suivre les indications suivantes, indépendamment du type de demande effectué :

  • Vérifiez qu'un objet peut être créé uniquement par les appelants qui ont une autorisation spécifique en émettant la demande au niveau de la classe de cet objet. Supposons, par exemple, que vous disposez d'une classe appelée myFileStream, qui dérive de la classe FileStream et que vous souhaitez vous assurer que seuls les appelants autorisés peuvent créer des instances de myFileStream. Placez une demande déclarative pour un objet FileIOPermission qui représente le droit d'accès au flux de données créé par myFileStream au niveau de la classe myFileStream.

  • Vous pouvez aussi mettre des demandes qui définissent ou obtiennent une propriété dans du code. Vous mettez généralement des demandes pour les autorisations moins restrictives sur l'accesseur get plutôt que sur l'accesseur set, à moins que la propriété ne contienne des informations sensibles telles qu'un mot de passe.

    RemarqueRemarque

    Les vérifications de sécurité basées sur les rôles ont une sémantique légèrement différente des vérifications de sécurité d'accès du code.Pour plus d'informations, consultez Sécurité basée sur les rôles.

    RemarqueRemarque

    Les demandes peuvent s'appliquer uniquement aux niveaux classe, méthode, événement et propriété ; les assemblys et les membres de variables individuelles non privées ne sont pas protégés par les demandes.Les demandes placées au niveau de l'assembly ou de la variable non privée n'entraîneront pas d'avertissement de compilation.Par conséquent, il est important d'utiliser des propriétés au lieu des membres publics afin de garantir la protection que fournissent les demandes.

Voir aussi

Référence

SecurityException

Concepts

Sécurité d'accès du code

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

Historique des modifications

Date

Historique

Motif

Juillet 2010

Suppression des informations obsolètes.

Résolution des bogues de contenu.