Dependency Property Security
Microsoft Silverlight will reach end of support after October 2021. Learn more.
Dependency properties should generally be considered to be public properties. The nature of the Silverlight property system prevents the ability to make security guarantees about a dependency property value.
This topic contains the following sections.
- Prerequisites
- Access and Security of Wrappers and Dependency Properties
- Property System Exposure of Dependency Properties
- Related Topics
Prerequisites
This topic assumes that you understand dependency properties from the perspective of a consumer of existing dependency properties on Silverlight classes, and that you have read Dependency Properties Overview and Custom Dependency Objects and Dependency Properties.
Access and Security of Wrappers and Dependency Properties
Typically, dependency properties are implemented along with "wrapper" CLR properties that simplify getting or setting the property from an instance. But the wrappers are really just convenience properties that implement calls to the underlying GetValue and SetValue static methods that are used when interacting with dependency properties. Security mechanisms applied to the wrappers do not apply to the underlying dependency property. Placing a security demand on the CLR wrapper will prevent the use of the convenience method but will not prevent calls to GetValue or SetValue. Similarly, placing protected or private access level on the wrappers does not provide any effective security. Declaring the dependency property identifier internal or private will not work, because then the Silverlight property system cannot operate properly.
Note also that Silverlight does not support true custom read-only dependency properties. (There are some read-only dependency properties that are part of the Silverlight 2 core API, but these rely on internal native support to enforce the read-only state.)
If you are writing your own dependency properties, you should declare the wrappers and the DependencyProperty identifier field as public members, so that callers do not get misleading information about the true access level of that property (because of its backing being implemented as a dependency property).
.gif "Note") Note: |
|---|
Declaring a DependencyProperty identifier field private is not forbidden, and it can conceivably be used to help reduce the immediately exposed namespace of a custom class, but such a property should not be considered "private" in the same sense as the CLR language definitions define that access level, for reasons described in the next section. |
Property System Exposure of Dependency Properties
It is not generally useful, and it is potentially misleading, to declare a DependencyProperty field with any access level other than public. That access level only prevents someone from getting a reference to the instance from the declaring class. But there are aspects of the property system that return a DependencyProperty even if the original static identifier is declared as nonpublic.
A Windows Presentation Foundation (WPF) dependency property has additional API exposure for dependency properties and support types that does not exist in Silverlight. The WPF security implications for a dependency property might have no immediate impact on your Silverlight implementation, but they could become a factor if you migrate an application from Silverlight to WPF.
See Also