When using principalpermissionattribute for permission control, pay attention to the usage of principalpermissionattribute.
1. principalpermissionattribute can only act on classes or their methods.
Principalpermissionattribute does not apply to interfaces and interface methods. For example, when defining a service contract for WCF, principalpermissionattribute cannot be placed on the service interface or its method.
2. Class-level permission control takes precedence over method-level permission control.
Class-level permission control is implemented during class instantiation, while method-level permission control is implemented before method execution. For example, for a common class, you can control permissions at both the class level and the method level. The class-level control is executed first. Therefore, basic or common permissions can be placed on the class, while some methods can have different special permissions.
3. Permission control should be placed on the base class instead of any derived class.
You cannot add permission control on the level of the derived class. You can only add permission control on the override method in the derived class. The permission control on the override method also replaces the permission control of the method in the base class. For the new method, you need to add permission control like the basic method. The basis for whether the permission control takes effect is to check which method is executed.
4. principalpermissionattribute should be used for public methods rather than private methods.
Private methods are not indispensable, but they are prone to overlap for permission control and are not conducive to permission control at the framework level. The most ideal permission control, for an execution path (within a main thread), if there is no need for Branch and its permission control, only one permission control is the best, to avoid performance problems caused by permission control. The idea of COC can be used for reference on this issue.