Demandes de liaison

Une demande de liaison engendre une vérification de la sécurité au cours de la compilation juste-à-temps et vérifie uniquement l'assembly appelant immédiat de votre code. La liaison survient lorsque votre code est lié à une référence de type, comprenant les références de pointeur fonction et les appels de méthodes. Si l'assembly appelant ne dispose pas des autorisations suffisantes pour établir un lien avec votre code, le lien n'est pas autorisé et une exception runtime est levée lorsque le code est chargé et exécuté. Les demandes de liaison peuvent être substituées dans les classes qui héritent de votre code.

Notez qu'un parcours de pile complet n'est pas effectué avec ce type de demande et que votre code est toujours susceptible de subir des attaques malveillantes. Par exemple, si une méthode de l'assembly A est protégée par une demande de liaison, un appelant direct dans l'assembly B est évalué selon les autorisations de l'assembly B Cependant, la demande de liaison n'évaluera pas de méthode dans l'assembly C si elle appelle indirectement la méthode de l'assembly A à l'aide de la méthode de l'assembly B. La demande de liaison spécifie uniquement les autorisations que les appelants directs dans l'assembly appelant immédiat doivent posséder pour effectuer une liaison avec votre code. Elle ne spécifie pas les autorisations que tous les appelants doivent posséder pour exécuter votre code.

Les modificateurs de parcours de la pile Assert, Deny et PermitOnly n'affectent pas l'évaluation des demandes de liaison. Comme les demandes de liaison n'effectuent pas de parcours de la pile, les modificateurs de parcours de la pile n'ont aucun effet sur les demandes de liaison.

Si une méthode protégée par une demande de liaison est accessible par l'intermédiaire de Réflexion, une demande de liaison vérifie alors l'appelant immédiat du code accessible par l'intermédiaire de la réflexion. Ceci est vrai à la fois pour la découverte d'une méthode et l'appel à une méthode, effectués à l'aide de la réflexion. Supposons par exemple que du code utilise la réflexion pour retourner un objet MethodInfo représentant une méthode protégée par une demande de liaison et qu'il passe cet objet MethodInfo à un autre code qui utilise l'objet pour appeler la méthode d'origine. Dans ce cas, la vérification de demande de liaison survient deux fois : une fois pour le code qui retourne l'objet MethodInfo et une fois pour le code qui l'appelle.

Remarque

Une demande de liaison exécutée sur un constructeur de classe statique ne protège pas le constructeur car les constructeurs statiques sont appelés par le système, hors du chemin d'exécution du code de l'application.Par conséquent, lorsqu'une demande de liaison est appliquée à l'ensemble d'une classe, elle ne protège pas l'accès à un constructeur statique, même si elle protège le reste de la classe.

Le fragment de code suivant spécifie de manière déclarative que tout code se liant à la méthode ReadData doit avoir l'autorisation CustomPermission. Cette autorisation est une autorisation personnalisée hypothétique et n'existe pas dans le .NET Framework. La demande est faite en passant un indicateur SecurityAction.LinkDemand à CustomPermissionAttribute.

<CustomPermissionAttribute(SecurityAction.LinkDemand)> _
Public Shared Function ReadData() As String
    ' Access a custom resource.
End Function  

[CustomPermissionAttribute(SecurityAction.LinkDemand)]
public static string ReadData()
{
    // Access a custom resource.
}

Voir aussi

Concepts

Extension des métadonnées à l'aide des attributs

Demandes de sécurité

Création de vos propres autorisations d'accès du code

Ajout de la prise en charge de la sécurité déclarative

Sécurité d'accès du code