将 ASP.NET 会员资格提供程序数据库与您自己的数据库一起使用？
我们正在开发一个 ASP.NET MVC 应用程序，目前它使用自己的数据库 ApplicationData 进行域模型，并使用另一个Membership 进行用户管理/会员提供商。
我们在控制器中使用data-annotations 进行访问限制。
[Authorize(Roles = "administrators, managers")]
这对于简单的用例非常有效。
当我们扩展应用程序时，我们的客户希望限制特定用户访问我们ApplicationData数据库的特定区域。
我们的每个产品都包含一个外键，引用产品组装的区域。
用户故事将是：
- 角色 NewYorkManagers 的用户应该只能编辑/查看在 New 中组装的产品约克。
我们创建了一个占位符表 UserRightsRegions，其中包含 UserId 和 RegionId。
如何链接 ApplicationData 和 Membership 数据库才能正常工作/具有跨数据库键引用< /代码>? （这样的事情甚至可能吗？）
我们非常感谢所有帮助！
We are developing an ASP.NET MVC Application that currently uses it's own database ApplicationData for the domain models and another one Membership for the user management / membership provider.
We do access restrictions using data-annotations in our controllers.
[Authorize(Roles = "administrators, managers")]
This worked great for simple use cases.
As we are scaling our application our customer wants to restrict specific users to access specific areas of our ApplicationData database.
Each of our products contains a foreign key referring to the region the product was assembled in.
A user story would be:
- Users in the role NewYorkManagers should only be able to edit / see products that are assembled in New York.
We created a placeholder table UserRightsRegions that contains the UserId and the RegionId.
How can I link both the ApplicationData and the Membership databases in order to work properly / having cross-database-key-references? (Is something like this even possible?)
All help is more than appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在我看来，您应该能够可靠地将数据库与标准 aspnet_db 集成，但我建议不要复制或替换 aspnet_users 表。
这是使用 aspnet_db 架构的所有提供程序的焦点，包括可能增强但不实现自定义替换的自定义提供程序。
为了最大限度地重用提供者堆栈/API 中经过严格测试的基础设施代码，最好遵循该流程。
您将需要非常关注任何修改的成员资格核心功能，并确保您的新约束在每种情况下都以预期的方式运行。
我发现会员故事中最需要关注的方面是删除用户，对删除用户存储过程进行简单的修改/添加就可以很好地管理这一点。
In my opinion, you should be able to integrate your database with the standard aspnet_db reliably, but I would advise against duplicating or replacing the aspnet_users table.
That is the focal point of all the providers that use the aspnet_db schema, including custom providers that may augment but do not implement custom replacement.
To maximize reuse of strong tested infrastructure code in the provider stack/API it is best to go with that flow.
You will want to be very attentive to any modified membership core functions and ensure that the way your new constraints behave in an expected fashion in each case.
The facet of the membership story that I have found needs the most attention is deleting a user, and a simple modification/addition to the delete user sproc can manage this capably.
听起来您可能需要创建自己的定制会员提供商。您可能（这里不是积极的）扩展现有的，这样您就不必完全重新发明它。 这里是来自ASP.net 描述了如何做到这一点。谷歌“asp.net 会员提供商”了解更多信息。
It sounds like you might need to create your own customized Membership Provider. You can probably (not positive here) extend the existing one so you don't have to completely reinvent it. Here is a video from ASP.net that describes how to do that. Google "asp.net membership provider" for tons more.
您可以尝试滚动自己的会员资格，或者像戴夫建议的那样延长会员资格。
创建您自己的
[Users]表，该表可以根据 aspnet_Membership 表进行填充。因此你可以更好地控制它。您还可以实施一个更复杂的配置文件系统。 .NET 团队现在改进了配置文件的存储方式，因此您现在可以将它们设置为存储在实际的表中，而不是“blobicizing”它们[感谢上帝]。
表配置文件提供程序
You can try rolling your own membership or just extend is like Dave suggests.
Create your own
[Users]Table which can be populated based off the aspnet_Membership table. So therefore you could have more control over it.You could also just implement a more involved Profiles system. The .NET team has improved the way profiles are stored now, so instead of "blobicizing" them, you can set them up to be stored in an actual table now [thank god].
Table Profile Provider
如果您找到合适的文章，那么扩展会员资格提供程序以允许额外的功能非常容易。我已将用户表移至主 SQL Server 表，并编写了自己的角色管理器，该角色管理器从单独的表中获取值。听起来您需要做的是在用户数据库中设置一个包含每个用户位置的表，然后在用户对象上创建一个类似“GetLocation()”的方法，该方法从数据库返回用户的位置，您然后可以使用它来过滤主数据库中的数据。以下是我在书签中翻来覆去的几篇文章，看看它们是否有帮助，如果您查看 ASP.NET 主站点或 google 查找会员提供程序扩展文章，那里有很多文章。
http://msdn.microsoft.com/en-us/library/ms998347。 ASPX
https://web. archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
http://msdn.microsoft.com/en-us/library/aa479048。 ASPX
If you find the right articles, it's really easy to extend the membership provider to allow for extra functionality. I've moved my users table to my main SQL server table and have written my own role manager that gets values from a separate table. What it sounds like you need to do is to set up a table in your users DB with the location of each user, then create a method on the user object something like "GetLocation()" that returns the user's location from the DB, you could then user that to filter your data from your main DB. Here's a few articles I had kicking aroundin my bookmarks, see if they help, if you have a look on the main ASP.NET site or google for membership provider extending articles, there are plenty around.
http://msdn.microsoft.com/en-us/library/ms998347.aspx
https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx
http://msdn.microsoft.com/en-us/library/aa479048.aspx
正如其他人指出的那样，有许多可用的优质资源可以帮助您使用现有数据库创建自定义提供程序。
看来您使用映射表正朝着正确的方向前进。我认为您缺少的一件事情是分布式查询。此链接特定于 Sql Server 2008。如果您正在使用 Sql Server 2005，则这里有一个指向 Sql Server 2005 文档的链接。
As the others have pointed out there are many good resources available that can help you with creating your custom provider using the existing database.
It looks like you are headed in the right direction with mapping tables. I think the one piece you are missing is Distributed Queries. This link is specific to Sql Server 2008. There is a link there to the documentation for Sql Server 2005 if that is what you are using.