有没有人真正使用Code Access Security来保护他们的程序集和/或方法？

Question

对我来说，大多数开发人员完全忽略了这些功能。人们更喜欢将安全例外处理为依赖于标准窗口角色和权限的通用例外，而不是学习使用CAS增强安全性的方法 - 可能是因为CAS在逻辑和命名方面相当混乱。

任何人都可以建议任何一般的经验法则/最佳实践，以最好的方式使用CAS吗？

Answer 1

是和否。

不幸的是，你是对的 - 开发人员很少使用CAS，更不用说充分利用它了。在极少数情况下，我看到他们实际上是这样做的（好吧，它不是真正的程序员，而是强迫他们的组织......）

除了用于允许用户限制从Internet下载的程序集（例如） - 虽然这很少在Silverlight之外部署 - 我已经看到CAS的两个主要用途。
首先是一般政策限制，通常是使用CAS的最简单方法（特别是因为VS可以为您自动生成策略文件）。当敏感企业（例如银行）对必须安全的系统进行第三方定制开发时，我已经看到了这种情况（很少）。这可以通过对他们不了解程序员正在做的事情添加额外的限制来使他们受益 其次是非常具体的链接需求，在（再次罕见的）情况下，您有一个以相对较高的权限运行的模块，并且只需要调用模块的特定程序集。例如，就在上周，我有一个客户端，其模块写入ActiveDirectory，并希望仅限制从特定系统访问此功能。

当然，CAS比这要大得多，但这些确实是两个最好的起点。作为一般规则，这当然适用于所有事情，不要仅仅因为它在那里使用它，除非它满足你的需要。政策是最简单的，最有意义的是提前到位。

Answer 2

另见this discussion。

问题很严重，因为很多代码（可能太多）都是完全信任的。然后进行的唯一检查就是PrincipalPermissionAttribute检查 - 其余大部分都被简单地绕过。所以在很多情况下没有多大意义！除非您正在加载外部（不受信任的）文件[因此需要CAS]，否则在许多情况下它不会添加很多（是的，有很多例外）。

CAS对于在沙箱中运行的客户端（例如从Internet下载）更有用。 Sliverlight采用了比普通.NET更严格的规则（尤其是反射）来实现这一目标。