我的网站有表单身份验证，一切都很顺利。现在我想创建一个子目录并让它也受密码保护，但是！我需要子目录使用一组完全不同于整个网站使用的登录/密码。
比如说，我有网站的用户存储在数据库的“用户”表中。但对于子目录，我希望用户从“SubdirUsers”表中获取。这可能有完全不同的结构。
因此，我需要将登录完全并行，如：
我不想要为子目录创建单独的虚拟应用程序，因为我想共享所有库，用户控件以及应用程序状态和缓存。换句话说，它必须是相同的应用程序。
我还不想要在“Users”表中添加一个标志，指示这是一个完整的网站用户还是子目录用户。用户列表必须来自不同的来源。
目前，我看到的唯一选项是为子目录滚动我自己的Forms Auth。
任何人都可以提出更好的选择吗？
答案 0 :(得分：1)
我认为您可以使用此代码验证任何提供商的用户
if (Membership.Providers["myprovider"].ValidateUser("USER", "PWD")) {
//your code
}
答案 1 :(得分：1)
您可以在子文件夹中包含单独的web.config文件，该文件仅包含该子文件夹的验证设置。请注意，您必须删除所有其他设置，因为有些设置只能在应用程序级别上。
<authorization configSource="alterativeSource.xml"/>
答案 2 :(得分：0)
您将无法仅使用FormsAuthentication实现此目的。
此问题场景是使用HttpModules的理想选择。 HttpModules可以拦截请求和响应管道。您需要编写2个HttpModule。
您可以在解决方案达到稳定状态后将这些模块合并到一个模块中，并且您可以很好地管理复杂性。
在您的解决方案中，您将需要一个存储子目录和用户授权和身份验证映射数据的数据库机制。您的HttpModules可以读取这些数据，以决定请求用户。
您可以从 here 开始。
答案 3 :(得分：0)
如果您的用户位于web.config文件中，我可以看到更好的答案，但由于您在数据库中使用用户，因此除了表单身份验证之外，您几乎不得不使用其他内容。您需要将子目录设置为允许任何用户，然后基本上使用会话重建表单身份验证。您可以创建页面类的子类，并使用它来保存您的所有例程以进行身份验证和重定向。然后，您不需要在子目录中的每个页面添加任何内容。
我知道这是你可能希望避免的答案，但形式认证对于这种复杂的情况来说太简单了。
答案 4 :(得分：0)
通常在登录后使用“授权”来确定给定用户可以使用哪些目录，资源等。
您是否考虑过为“主”目录创建角色，为“sub”目录创建第二个角色，然后应用授权标记（即在web.config中）？您需要实现一个授权提供程序，但这听起来像是一个比拥有多个用户表更好的长期解决方案。
澄清无论授权（即凭据检查或密码等），您仍然需要在某处定义用户角色，因此为了参数，我们假设一个“用户表”。 （如果您愿意，没有什么能阻止它成为独立存储中的XML文件。） NB 用户来自不同来源并不重要。这应该反映在用户表的模式中（即标志或其他列等）。如果你对抗这种常见模式，你可能最终会做更多的工作。
如果有一个例外，将来可能会有另一个例外......
答案 5 :(得分：0)
这可以帮助您 - numina.codeplex.com
答案 6 :(得分：0)
我没试过这个，但我认为它会起作用。
您可以拥有两个成员资格提供程序（即ASPNETDB_1和ASPNETDB_2。）
这些是在web.config的成员资格提供程序部分中指定的。所以你需要在每个子目录中有一个单独的web.config，我知道你可以这样做。
在网站的根目录中，我猜你不会有表单身份验证。您可能只有一个启动页面，要求用户选择哪个子目录（或者您可以只使用子域名（firstdir.mysite.com，secondir.mysite.com）或http：/mysite.com/firstdirectory或http：/ mysite。 COM / secondirectory。
我不确定这种方法相对于虚拟目录的优势，但是根目录可以包含一些不需要身份验证的ASP程序。
我知道您正在寻找一种“开箱即用”的解决方案，并且不想“自己动手”。但是，标准成员资格提供程序允许您为每个用户建立配置文件 - 然后很容易为每个单独的用户维护功能设置一个带有列表视图的用户维护表单，并按角色或配置文件值进行过滤（例如，组织ID）。使用成员资格提供程序类，我个人发现这很容易开箱即用（如果使用所有拖放控件，SqlDatasource + listview - 不需要VB或C编码，可能需要一小时创建维护表单）。但是，单独的提供者和webconfigs也可以做到这一点。