SecurityAttribute和CodeAccessSecurityAttribute有什么区别?

时间:2011-10-08 12:23:59

标签: .net security

在创建自定义安全属性(在我的情况下声明性地要求自定义权限)时,继承SecurityAttributeCodeAccessSecurityAttribute有什么实际区别?

反映类型,CodeAccessSecurityAttribute似乎没有以任何有意义的方式扩展SecurityAttribute,所以我只能假设CAS系统使用该类型,但是这个代码被烘焙到CLR中,所以我无法读到它。

自定义权限的所有示例都从CodeAccessSecurityAttribute继承,但没有解释原因。实际上,PrincipalPermissionAttribute继承自CodeAccsesSecurityAttribute,尽管不是严格的CAS相关权限(因为它具有不同的语义并引用当前主体,而不是授予调用程序集的权限)。

我的问题是学术问题 - 我可以从CodeAccessSecurityAttribute继承进步 - 但我想知道原因!

2 个答案:

答案 0 :(得分:1)

我不建议使用这些属性。它们的功能太复杂了,微软自己也承认了这一点。例如。对于Silverlight,它们已经过时了:System.Security.Permissions (Silverlight)

答案 1 :(得分:1)

您认为CLR本身使用CodeAccessSecurityAttribute类型是正确的。这实际上是CLR提供的AOP样式行为,它将在运行时验证(和/或修改)CodeAccessSecurityAttribute子类型实例创建的权限。您不能将SecurityAttribute用于基类的原因是CLR仅扫描CodeAccessSecurityAttribute个子类型。它将忽略SecurityAttribute的其他子类型。

至于为什么会出现这种情况,我不知道任何公开的文档。但是,似乎可以安全地假设它可能只是.NET开发历史中不幸的副产品。很容易想象在.NET 1.0的设计/开发周期中引入非CAS权限的情况,并且对这些权限的支持使其成为BCL但不进入CLR。鉴于实际创建非CAS权限的开发人员数量很少,“修复”CLR权限属性检测器可能从未被认为足够重要,值得任何后续.NET发布周期中的任何认真关注。