用于页面访问控制的PrincipalPermission与web.config

Question

我目前拥有web.config中的访问权限：

 <location path="Account">
    <system.web>
      <authorization>
        <allow users="?"/>
      </authorization>
    </system.web>
 </location>
 ...

我不喜欢这个有两个原因：

1. web.config在我的网站建立时变得一团糟
2. 我不确定将网页访问规则与页面本身分开是很好的安全性。毕竟，我大部分时间都在编辑aspx / c＃文件而不是web.config，所以事情往往会滑落。
3. 这是一个非常奇怪的...我刚刚添加了ASP.NET4路由，它改变了URL。所以，我的web.config权限突然不再有效！与上面第2点相似。

我认为最好只使用PrincipalPermission作为每个aspx中涉及的classes / c＃文件的安全属性。我的问题：

• 这是由任何人完成的，还是一个坏主意？
• 更重要的是......我的PrincipalPermission属性生成异常（好），但不会将用户重定向回登录页面（错误）。可以修复吗？

Answer 1

我知道一个可能有用的技巧 - 如果您将页面放在单独的文件夹中，则每个文件夹可以有一个本地web.config。不包括所需的全局Web配置。 请参阅“配置范围设置”部分here中的“ASP.NET应用程序子目录”行。

Answer 2

主要权限在表面上似乎是一个好主意。但是，在这条路线下，权衡比使用“普通”安全方法可能导致的任何大量配置都要难得多。恕我直言，最大的缺点是，他们打下了一个潜在例外的雷区，无论你身后的人是谁都需要解决。您的所有安全性都变得非常硬编码，因为它们是编译时属性，因此您无法轻松地将它们与运行时配置设置相匹配。对于每个规则都有例外情况的现实场景会发生什么？

无论如何，如果你必须这样做，你最好的朋友将成为一个自定义的IPrincipal实现来解决很多PrincipalPermissionAttribute强加的约束。

Answer 3

我刚刚在另一个问题here上发布了答案。

我不想使用web.config进行授权，因此我想出了一个使用Attribute和自定义Principal的MVC实现。