Demandes

Article
08/10/2011

Vous pouvez utiliser l'appel de demande de sécurité de manière déclarative ou impérative afin de spécifier les autorisations que les appelants directs ou indirects doivent posséder pour accéder à votre bibliothèque. Les appelants directs appellent de manière explicite les méthodes statiques ou d'instance de votre bibliothèque tandis que les appelants indirects appellent les méthodes statiques ou d'instance d'une autre bibliothèque qui elle-même appelle votre bibliothèque. Lorsque vous utilisez une demande, toute application incluant votre code ne s'exécutera que si tous les appelants directs et indirects ont les autorisations spécifiées par la demande. Les demandes sont particulièrement utiles dans les situations où votre bibliothèque de classes utilise des ressources protégées auxquelles vous ne souhaitez pas que du code n'ayant aucun niveau de confiance accède. Les demandes peuvent être placées dans du code à l'aide de la syntaxe impérative ou déclarative.

Notez que des demandes sont déjà associées à la plupart des classes dans le .NET Framework ; vous n'avez donc pas besoin de faire une demande supplémentaire chaque fois que vous utilisez une classe qui accède à une ressource protégée. Par exemple, la classe StreamWriter fait automatiquement une demande de sécurité pour FileIOPermission à chaque ouverture. Si vous faites une demande pour FileIOPermission lors de l'utilisation de la classe StreamWriter, vous provoquerez un parcours de pile redondant et inefficace. Nous vous conseillons d'utiliser les demandes pour protéger les ressources personnalisées qui nécessitent des autorisations personnalisées.

Les demandes peuvent être déclaratives ou impératives.

Parcours de la pile

Les demandes appliquent la sécurité en exécutant une analyse (appelée parcours de la pile) dans laquelle chaque fonction d'appel (ou frame de pile) dans la pile des appels actuelle est examinée pour l'autorisation spécifiée. Lorsqu'une demande est déclenchée, les événements suivants se produisent.

Le parcours de la pile commence au niveau du frame de pile des appelants, non au niveau de la pile actuelle où la demande se produit. Par exemple, si la méthode A appelle la méthode B et si la méthode B a une demande, le parcours de la pile commence au niveau du frame de pile de la méthode A. La méthode B n'est jamais évaluée dans le cadre du parcours de la pile.
Le parcours de la pile s'effectue via la pile des appels jusqu'à ce qu'il atteigne le point d'entrée du programme de la pile (habituellement, la méthode Main) ou jusqu'à un modificateur de parcours de la pile, tel qu'une assertion. Pour plus d'informations sur les modificateurs de parcours de la pile, consultez Substitution des vérifications de sécurité.
Lorsqu'une demande et un modificateur de parcours de la pile (une assertion, par exemple) pour la même autorisation apparaissent sur le même frame de pile, la demande est prioritaire.
La syntaxe déclarative et la syntaxe impérative ne présentent aucune différence de comportement.
Notez qu'une demande placée sur le point d'entrée de votre programme n'est jamais évaluée car le parcours de la pile commence toujours au niveau du frame de pile appelant, mais dans ce cas, il n'y a pas de frame appelant à évaluer. Par conséquent, les demandes placées sur le point d'entrée d'un programme réussissent toujours.

Demandes déclaratives

Les demandes déclaratives placent des informations dans les métadonnées de votre code à l'aide d'attributs. Vous pouvez utiliser la syntaxe déclarative pour placer une demande au niveau de la classe ou de la méthode de votre code.

Si vous placez une vérification de sécurité déclarative au niveau de la classe, elle s'applique à chaque membre de la classe. Cependant, si vous placez une vérification de sécurité déclarative au niveau du membre, elle s'applique uniquement à ce membre et ignore l'autorisation spécifiée au niveau de la classe, s'il en existe une. Supposons par exemple que vous spécifiiez au niveau de la classe que l'AutorisationA est requise et que vous indiquiez que l'AutorisationB est requise pour la Méthode1 de cette classe. Lorsque la Méthode 1 est appelée, une vérification de sécurité cherchera uniquement l'AutorisationB, mais les autres méthodes de la classe exigeront toujours l'AutorisationA.

L'exemple suivant place une demande déclarative pour une autorisation personnalisée appelée CustomPermission sur tous les appelants de la méthode ReadData. Cette autorisation est une autorisation personnalisée hypothétique et n'existe pas dans le .NET Framework. L'autorisation personnalisée a un CustomPermissionAttribute défini séparément qui effectue la demande. Dans ce cas, elle prend un indicateur SecurityAction.Demand afin de spécifier le type de demande que l'attribut effectuera.

<CustomPermissionAttribute(SecurityAction.Demand, Unrestricted := True)>Public Shared Function  ReadData() As String
   'Read from a custom resource.
End Function

[CustomPermissionAttribute(SecurityAction.Demand, Unrestricted = true)]
public static string ReadData()
{
   //Read from a custom resource.
}

Demandes impératives

Les demandes impératives sont placées au niveau de la méthode de votre code en créant une nouvelle instance d'un objet d'autorisation et en appelant la méthode Demand de cet objet. La syntaxe impérative ne peut pas être utilisée pour placer des demandes au niveau de la classe.

La demande impérative que vous placez dans votre code protège efficacement tout le code restant dans la méthode dans laquelle la méthode Demand est appelée. La vérification de sécurité est effectuée lorsque Demand est exécuté. Si la vérification de sécurité échoue, une SecurityException est levée et le reste du code de cette méthode ou de ce membre n'est jamais exécuté sauf si SecurityException est interceptée et gérée.

L'exemple suivant utilise la syntaxe impérative pour placer une demande sur tous les appelants pour l'autorisation personnalisée CustomPermission. Ce code crée une nouvelle instance de la classe CustomPermission, passant l'indicateur PermissionState.Unrestricted au constructeur. La méthode Demand est alors appelée.

Public Shared Sub ReadData()
   Dim MyPermission As New CustomPermission(PermissionState.Unrestricted)
   MyPermission.Demand()
   'Read from a custom resource.
End Sub

public static void ReadData()
{
   CustomPermission MyPermission = new CustomPermission(PermissionState.Unrestricted);
   MyPermission.Demand();

   //Read from a custom resource.
}

Remarque
Le comportement d'optimisation pour l'opération de demande diffère entre les plateformes 64 bits et 32 bits.Sur les plateformes 64 bits, une demande ne vérifiera pas le jeu d'autorisations de l'assembly qui contient la demande si aucun autre assembly appelant n'est présent.Toutefois, cette optimisation ne provoque pas une élévation de privilège car un parcours de la pile est toujours exécuté lorsque des assemblys appelants sont présents.Sur les plateformes 32 bits, l'opération de demande vérifie le jeu d'autorisations de l'assembly qui contient la demande et tous les assemblys appelants.

Le comportement d'optimisation pour l'opération de demande diffère entre les plateformes 64 bits et 32 bits.Sur les plateformes 64 bits, une demande ne vérifiera pas le jeu d'autorisations de l'assembly qui contient la demande si aucun autre assembly appelant n'est présent.Toutefois, cette optimisation ne provoque pas une élévation de privilège car un parcours de la pile est toujours exécuté lorsque des assemblys appelants sont présents.Sur les plateformes 32 bits, l'opération de demande vérifie le jeu d'autorisations de l'assembly qui contient la demande et tous les assemblys appelants.