Безопасность свойства зависимости

Свойства зависимости, как правило, считаются открытыми. Суть системы свойств Windows Presentation Foundation (WPF) такова, что дать гарантии безопасности в отношении значений свойств зависимостей невозможно.

Доступ к программам-оболочкам и свойствам зависимости и их безопасность

Как правило, свойства зависимости реализуются вместе со свойствами поддержки общеязыковой среды выполнения (CLR) программы-оболочки, которые упрощают получение или настройку свойства от экземпляра. Но программы-оболочки это всего лишь удобный способ для реализации базовых статических вызовов GetValue и SetValue, которые используются при взаимодействии со свойствами зависимостей. Другими словами, свойства предоставляются как свойства поддержки общеязыковой среды выполнения (CLR), которые реализуются свойством зависимости, а не закрытым полем. Механизмы безопасности, применяемые к программам-оболочкам, не поддерживают параллели между поведением системы свойств и доступом базового свойства зависимости. Размещение защищенного запроса для программы-оболочки предотвращает только использование универсального метода, но не предотвращает вызовы для GetValue или SetValue. Аналогично: размещение защищенного или закрытого уровня доступа в программе-разработчике не обеспечивает эффективную защиту.

При создании собственных свойств зависимости необходимо объявить программы-обработчики и поле идентификатора DependencyProperty в качестве открытых членов, чтобы вызывающие объекты не получали противоречивую информацию об истинном уровне доступа этого свойства (из-за того, что его хранилище реализовано как свойство зависимости).

Что касается пользовательского свойства зависимости, его можно зарегистрировать как доступное только для чтения свойство зависимости; это неэффективный способ защиты от перенастройки свойства кем-либо, у кого нет ссылки на ключ DependencyPropertyKey для этого свойства. Дополнительные сведения см. в разделе Свойства зависимостей "только для чтения".

Примечание.

Объявлять поле идентификатора DependencyProperty закрытым не запрещено; кроме того, такой подход можно использовать для уменьшения немедленно предоставляемого пространства имен пользовательского класса; однако такое свойство не стоит считать "закрытым" в таком же смысле, в каком определения языка поддержки общеязыковой среды выполнения (CLR) определяют этот уровень доступа (по причинам, описанным в следующем разделе).

Предоставление системы свойств свойствам зависимости

Как правило, не требуется (да и может привести к путанице) объявлять свойство DependencyProperty в качестве какого-либо уровня доступа, кроме открытого. Такая настройка уровня доступа просто лишит возможности получить ссылку на экземпляр из объявляющего класса. Однако существует несколько аспектов системы свойств, которые вернут свойство DependencyProperty в качестве способа идентификации определенного свойства в том виде, в котором оно существует в экземпляре класса или экземпляре производного класса; этот идентификатор по-прежнему используется в вызове SetValue, даже если исходный статический идентификатор объявляется неоткрытым. Также виртуальные методы OnPropertyChanged получают информацию о любых существующих свойствах зависимостей, у которых изменилось значение. В дополнение к этому, метод GetLocalValueEnumerator возвращает идентификаторы для любых свойств экземпляров с локально заданным значением.

Проверка и безопасность

Применение требования к методу ValidateValueCallback и ожидание сбоя проверки при сбое требования с целью предотвратить настройку свойства не является адекватным средством обеспечения безопасности. Кроме того, если вызывающие объекты работают в домене приложения, злоумышленники могут подавить принудительное аннулирование устанавливаемых значений посредством ValidateValueCallback.

См. также

• Пользовательские свойства зависимостей