我有一个使用表单身份验证来验证一种类型的用户的应用程序。此应用程序中的某个部分需要使用数据库中的其他表对另一种类型的用户进行身份验证。如果第二种类型的用户会话超时，则会发生问题，将其带到主Web.Config的"表单身份验证"部分中定义的登录页面，而不是第二种类型的用户的登录页面。我正在寻找解决此问题的方法。一个想法是在IIS中为该部分创建一个应用程序，为该文件夹创建一个Web.Config并添加另一个"表单身份验证"部分。在我的实验中，这似乎不起作用。我缺少明显的东西吗？有什么见解吗？

解决方案

IIRC，身份验证适用于每个文件夹。因此，如果所有需要第二种身份验证的页面都位于具有其自身配置的特定子文件夹中，那么我们应该能够做到这一点。

但是，不是100％可以肯定，因此，如果某个知识渊博的人可能与我矛盾，我将删除响应。

我们可能需要仔细检查语法，但是顶级web.config可以包含任意数量的标签。

<location>...</location>

在内部，我们可以为所需的任何文件夹/文件指定单独的配置参数。在这里寻找参考。

编辑：策略，我忽略了正确设置代码格式

我们不能在<location>标记内包含<authentication>部分，因此必须将子文件夹设置为它自己的IIS(和ASP.NET)应用程序。因此，我们应该能够自己运行该小节。

我认为500.19是"无法读取或者解析web.config"错误，它有详细信息吗？我们可能需要打开远程错误(或者检查事件查看器)以查看它们。如果仍然有问题，请发布一小段web.config。

顺便说一句，我从来都不是嵌套应用程序的忠实拥护者，并且可能更喜欢让普通Login.aspx页面作为MemberOf来处理它，或者重定向到SpecialUserLogin.aspx之类。嵌套应用程序是用于设置和测试IME的PITA(例如，尽管我们可以为它做两个单独的项目，并且在部署时合并使用，但我什至认为我们甚至无法在Cassini下使它运行)。

是的你可以。 Web.config文件具有带有覆盖功能的树状继承体系结构。意味着我们可以通过在子文件夹中放置一个web.config文件并指定不同的配置设置来修改该设置。

以我理解这个问题的方式，我们有两种解决方案，第一种是查看角色，整个Provider模型将是一个不错的起点。否则，最好的选择是将应用程序分为两部分，分解第二个用户类型区域，然后通过虚拟目录将其包含回到主项目中。只要记住虚拟目录是从父目录web.config继承其权限的，所以我们将需要使用<Location>标签来删除虚拟目录的身份验证，然后在虚拟目录web.config中定义新的表单身份验证。如果我们需要"表单身份验证"下的Windows身份验证(NTLM)，则此方法效果很好。