Partager via


Sécurité des propriétés de dépendance

Les propriétés de dépendance doivent généralement être considérées comme des propriétés publiques. La nature du système de propriétés Windows Presentation Foundation (WPF) empêche la possibilité de garantir la sécurité d’une valeur de propriété de dépendance.

Accès et sécurité des wrappers et des propriétés de dépendance

En règle générale, les propriétés de dépendance sont implémentées avec des propriétés « wrapper » CLR (Common Language Runtime) qui simplifient le processus pour obtenir ou définir la propriété d'une instance. Mais les wrappers sont vraiment des méthodes pratiques qui implémentent les appels statiques sous-jacents GetValue et SetValue utilisés pour interagir avec les propriétés de dépendance. ** En y réfléchissant autrement, les propriétés sont exposées en tant que propriétés CLR (Common Language Runtime) qui sont soutenues par une propriété de dépendance plutôt que par un champ privé. Les mécanismes de sécurité appliqués aux wrappers ne sont pas alignés avec le fonctionnement du système de propriétés et l'accès aux propriétés de dépendance de base. Placer une demande de sécurité sur l'enveloppe empêchera uniquement l'utilisation de la méthode pratique, mais ne bloquera pas les appels à GetValue ou SetValue. De même, le placement d’un niveau d’accès protégé ou privé sur les wrappers ne fournit aucune sécurité efficace.

Si vous écrivez vos propres propriétés de dépendance, vous devez déclarer les wrappers et le champ d’identificateur DependencyProperty comme membres publics, afin que les utilisateurs ne soient pas induits en erreur sur le niveau d’accès réel de cette propriété, en raison du fait que son stockage est implémenté en tant que propriété de dépendance.

Pour une propriété de dépendance personnalisée, vous pouvez enregistrer votre propriété comme une propriété de dépendance en lecture seule, ce qui constitue un moyen efficace d'empêcher qu'une propriété ne soit définie par quelqu'un qui ne possède pas de référence au DependencyPropertyKey pour cette propriété. Pour plus d’informations, consultez Read-Only Propriétés de Dépendance.

Note

La déclaration d’un champ d’identificateur DependencyProperty privé n’est pas interdite, et elle peut être utilisée de manière concevable pour réduire l’espace de noms immédiatement exposé d’une classe personnalisée, mais une telle propriété ne doit pas être considérée comme « privée » dans le même sens que les définitions de langage CLR (Common Language Runtime) définissent ce niveau d’accès, pour des raisons décrites dans la section suivante.

Exposition du système de propriétés des dépendances

Il n’est généralement pas utile, et il est potentiellement trompeur, de déclarer une DependencyProperty comme n’importe quel niveau d’accès autre que public. Ce paramètre de niveau d’accès empêche uniquement une personne d’obtenir une référence à l’instance de la classe déclarante. Mais il existe plusieurs aspects du système de propriétés qui retournent une DependencyProperty comme moyen d’identifier une propriété particulière telle qu’elle existe sur une instance d’une classe ou d’une instance de classe dérivée, et cet identificateur est toujours utilisable dans un appel SetValue même si l’identificateur statique d’origine est déclaré comme non public. En outre, OnPropertyChanged méthodes virtuelles reçoivent des informations sur toute propriété de dépendance existante qui a changé de valeur. En outre, la méthode GetLocalValueEnumerator retourne des identificateurs pour n’importe quelle propriété sur les instances avec une valeur définie localement.

Validation et sécurité

L’application d’une demande à un ValidateValueCallback et l’attente de l’échec de validation sur un échec de demande pour empêcher la définition d’une propriété n’est pas un mécanisme de sécurité adéquat. L’invalidation de valeur définie appliquée via ValidateValueCallback peut également être supprimée par des appelants malveillants, si ces appelants fonctionnent dans le domaine de l’application.

Voir aussi