C# 页面访问控制的PrincipalPermission与web.config

我目前在

web.config

中拥有访问权限：

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

...

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

web.config

在我的网站建设过程中变得一团糟

我不确定保持网页访问规则与网页本身如此分离是否安全。毕竟，我每天大部分时间都在编辑aspx/c#文件，而不是web.config，所以事情往往会出错

这是一个非常奇怪的问题。。。我刚刚添加了ASP.NET4路由，它会更改URL。因此，我的web.config权限突然失效！与上文第2点类似

我在想，最好只使用PrincipalPermission作为每个aspx中涉及的类/c#文件的安全属性。我的问题:

• 这是谁做的，还是一个坏主意
• 更重要的是。。。My PrincipalPermission属性生成异常（良好），但不会将用户重定向回登录页（不良）。这个问题能解决吗

---

我知道一个可能有用的诀窍——如果将页面放在单独的文件夹中，每个文件夹都可以有一个本地web.config。不需要包含在全局web配置中。

---

请参阅“配置设置范围”部分表格的“ASP.NET应用程序子目录”行。

我知道一个可能有用的技巧-如果将页面放在单独的文件夹中，则每个文件夹都可以有一个本地web.config。不需要包含在全局web配置中。

---

请参阅“配置设置范围”部分表格的“ASP.NET应用程序子目录”行。

从表面上看，主体权限似乎是个好主意。但是，沿着这条路走下去，取舍变得比使用“正常”安全方法可能得到的任何大量配置都要糟糕得多。IMHO最大的缺点是，它们为你身后的人设置了一个潜在的例外雷区，让他们需要解决。您的所有安全性都变得相当硬编码，因为它们是编译时属性，所以您无法轻松地将它们与运行时配置设置相匹配。在现实世界中，每一条规则都有例外，那会发生什么呢

---

无论如何，如果您必须这样做，那么您最好的朋友将是一个定制的IPrincipal实现，以解决PrincipalPermissionAttribute施加的许多约束。

从表面上看，Principal权限似乎是一个好主意。但是，沿着这条路走下去，取舍变得比使用“正常”安全方法可能得到的任何大量配置都要糟糕得多。IMHO最大的缺点是，它们为你身后的人设置了一个潜在的例外雷区，让他们需要解决。您的所有安全性都变得相当硬编码，因为它们是编译时属性，所以您无法轻松地将它们与运行时配置设置相匹配。在现实世界中，每一条规则都有例外，那会发生什么呢

---

无论如何，如果你必须这样做，你最好的朋友将是一个定制的IPrincipal实现，以解决PrincipalPermissionAttribute强加的许多约束。

我刚刚发布了另一个问题的答案

---

我不想使用web.config进行授权，所以我提出了一个类似MVC的实现，使用了一个属性和一个自定义主体。

我刚刚发布了另一个问题的答案

---

我不想使用web.config进行授权，所以我提出了一个类似MVC的实现，它使用了一个属性和一个自定义主体。

什么意思？安全性变得相当硬？如果不重新编译就无法更改它？什么是安全性变得相当硬编码？不重新编译就无法更改它？