4

在我看来,大多数开发人员完全忽略了这个功能。人们更喜欢将安全异常作为依赖标准 Windows 角色和权限的通用异常来处理,而不是学习使用 CAS 方法来增强安全性——可能是因为 CAS 在其逻辑和命名方面相当混乱。

任何人都可以建议任何一般的经验法则/最佳实践,以干净的方式以最佳方式使用 CAS 吗?

4

2 回答 2

3

是和不是。

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

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

当然,CAS 比这要大得多,但这确实是两个最好的起点。作为一般规则,这当然适用于一切,不要仅仅因为它在那里就决定使用它,除非它满足你的需求。政策是最简单的,也是最有意义的提前实施。

于 2008-10-05T00:18:24.263 回答
2

另请参阅此讨论

由于大量代码(可能太多)在完全信任的情况下运行,因此问题变得更加严重。然后完成的唯一检查是诸如 PrincipalPermissionAttribute 检查之类的检查——其余的大部分都被简单地绕过了。所以在很多情况下没有多大意义!除非您正在加载外部(不受信任的)文件[因此需要 CAS],否则在许多情况下它根本不会增加很多(是的,有很多例外)。

CAS 对于在沙箱中运行的客户端(例如从 Internet 下载)更有用。Sliverlight 将这一点发挥到了极致,与常规 .NET 相比,它具有更严格的规则(尤其是在反射方面)。

于 2008-10-04T21:12:27.557 回答