我们正在开发一个ASP.NET MVC应用程序,它目前使用它自己的数据库ApplicationData
作为域模型,另一个Membership
用于用户管理/成员资格提供程序。
我们在控制器中使用data-annotations
进行访问限制。
[Authorize(Roles = "administrators, managers")]
这对于简单的用例来说非常有用。
在扩展应用程序时,我们的客户希望限制specific users
访问ApplicationData
数据库的特定区域。
我们的每一种产品都包含一个外键,指的是产品组装所在的地区。
用户故事将是:
我们创建了一个占位符表UserRightsRegions
,其中包含UserId
和RegionId
。
如何将ApplicationData
和Membership
数据库链接起来以便正确工作/拥有cross-database-key-references
?(像这样的甚至可能是吗?)
所有的帮助都是非常感谢的!
发布于 2010-03-10 21:47:24
在我看来,您应该能够可靠地将数据库与标准aspnet_db集成,但我建议不要复制或替换aspnet_users表。
这是使用aspnet_db架构的所有提供程序的焦点,包括可能增加但不实现自定义替换的自定义提供程序。
为了最大限度地重用提供者堆栈/API中经过强测试的基础结构代码,最好使用该流程。
您将希望非常关注任何修改的成员核心功能,并确保新约束在每种情况下都以预期的方式运行。
我发现最需要注意的成员角色是删除用户,而对delete用户sproc进行简单的修改/添加就可以很好地管理这个问题。
发布于 2010-03-10 15:37:27
听起来,您可能需要创建自己的自定义成员资格提供程序。您可能(在这里不是积极的)扩展现有的,这样您就不必完全重新发明它。这里是来自ASP.net的一段视频,描述了如何做到这一点。谷歌"asp.net会员提供商“提供的更多信息。
发布于 2010-03-10 15:43:22
你可以试着滚动你自己的会员,或者像戴夫建议的那样扩大你的范围。
创建您自己的[Users]
表,它可以基于aspnet_Membership表填充。所以你可以更好地控制它。
您也可以实现一个更复杂的概要文件系统。.NET团队现在已经改进了配置文件的存储方式,所以您可以将它们设置为存储在一个实际的表中,现在谢天谢地,而不是对它们进行“浮点化”。
表配置文件提供程序
https://stackoverflow.com/questions/2418034
复制相似问题