您将不得不解决此问题,因为您无法更改默认webpages_
前缀或(AFAIK)表所在的数据库架构。
Simple Membership 提供程序被设计为高度可定制的,但是开箱即用它可以为您节省大量工作,而不是滚动您自己的提供程序。因此,让我们假设更好的选择是找到一种使用它的方法。解决方案是:
- 两个数据库;或者
- 如果您被单一数据库所困,那么您可以使用角色来分隔您的用户。
使用角色的唯一小缺点是您将不得不在UserProfile
课堂上更加努力地工作。通常,您会将任何额外的用户属性放在此类上。如果您的两个站点使用不同的用户属性,则必须使用Shared Primary Key Associations之类的方法对表进行水平分区。
在我看来,这实际上比在不同的数据库甚至同一个数据库中维护两组不同的简单成员表要少得多。无论如何,这还不错,诸如“LastLoginAt”之类的共享属性可以进入UserProfile
(因此您可以为两个站点开发一个通用库),并且诸如“InternalExtensionNumber”之类的站点特定属性可以进入特定于您公司用户的分区表。
有什么缺点?好吧,如果有人可以访问用户角色表,他们可以分配一个公共用户来访问私有站点。也就是说,如果有人可以在用户角色表中执行此操作,那么您可能已经受到攻击,而且情况不会变得更糟。
例子:
如果在站点 1 上注册的每个用户都被赋予了一个角色“PublicUser”,而在站点 2 上注册的每个用户都被赋予了一个角色“AdminUser”,那么在给定站点中强制执行一个强制角色就不难了,例如你可以在公司应用程序中装饰每个需要授权的控制器:
[Authorize(Roles = "PrivateUser")]
或者,您可以在整个站点中强制执行站点角色的授权。为此,您可以使用该属性AuthorizeAttribute
并将其注册为站点过滤器,然后使用AllowAnonymousAttribute
允许访问公共方法:
// Add this to global.asax.cs to enforce authorization on all controllers.
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
// Add a setting to the web.config to specify the site role,
// and then you can use the same value consistently when
// registering users and assigning them a role.
string siteRole = System.Configuration.ConfigurationManager.AppSettings["SiteRole"];
filters.Add(new System.Web.Mvc.AuthorizeAttribute() { Roles = siteRole });
}
如果您想走得更远,您可以通过创建自己的并在站点或控制器级别适当使用它来扩展授权属性。