当使用具有不同应用程序名称的多个角色提供程序时，如何防止重复的成员身份用户? [英] How do I prevent duplicate membership users when using multiple roleproviders with different application names?
问题描述
我有一个使用"/"默认应用程序名称的成员资格提供程序.然后，我有多个应用程序共享相同的成员资格提供程序配置.每个应用程序都有自己的角色提供程序配置，它们都与成员资格提供程序共享相同的数据库，但是使用不同的应用程序名称将其角色相互隔离.
当我创建成员时，会创建一条用户记录，并因此在所有应用程序之间共享.然后，我为每个应用程序创建唯一的特定角色，因为它们使用不同的应用程序名称.
我遇到的问题是当我在已经存在的成员上调用Roles.AddUserToRole时.角色提供者无法识别用户，因为成员资格和角色提供者的应用程序名称上下文不同，因此，角色创建者将继续为角色所属的应用程序名称创建新的用户记录.
如何避免在成员资格和角色提供者之间不共享应用程序名称的情况下创建这些重复的用户记录?
记录实际上不是重复项".
了解提供者与aspnet_Users表的角色之间的关系可能有助于清除此问题.
首先，请理解MembershipProvider和RoleProvider并不相互依赖，除了在MembershipProvider.DeleteUser()方法中存在一些令人担心的出血外，我将在后面进行解释.
成员身份的作用是对用户进行身份验证，并在身份验证的帮助下保护对您资源的访问.
角色的角色是通过角色分配来控制对资源的访问.
这是2个独立的问题，并且与aspnet_Users可能暗示的状态无关.
一个突出的问题是，用于连接所有提供程序的值是username. userid guid相似，如果所有提供者都使用相同的应用程序名称，则为任何用户名仅创建一个aspnet_users记录，因为每个提供者要做的第一件事就是检查aspnet_users中是否有匹配的用户名和应用程序名称.如果找到一个，则使用它；如果找不到，则创建一个，并为用户标识分配一个GUID.
虽然userId guid似乎是全局"标识符，但事实并非如此.
因此，需要注意的是-如果您知道接下来要解决的问题，则可以通过对每个成员身份实例使用相同的应用程序名称，对每个角色实例使用不同的应用程序名称，来使用公共成员身份存储来使用独立的角色提供程序./p>
我前面提到的(真正愚蠢的)违反关注分离的问题涉及到调用DeleteUser(deleteRelatedData)时SqlMembershipProvider采取的操作.然后，SqlMembershipProvider的行为就好像它是战斗中的唯一狗一样，越过角色和个人资料以仅使用其键删除记录，从而错过您希望消失的记录.
考虑:(这是使用上述的单一成员身份，多个角色的设置)
您创建具有成员身份的用户"John"，并使用角色"为他分配一些角色.现在，您必须在aspnet_users中记录John，并且一切正常进行. 约翰"是一位经理，并分配了相应的高级职位.
由于某种原因，约翰"成为被解雇的人"，并通过成员资格被删除.如前所述，在我们独特的场景中，删除了成员记录，但保留了角色信息.
聘请了新的约翰"来接听电话，并为他创建了会员用户.
在业余时间里，约翰探索了公司的内部网，不敢相信自己能做多少很棒的事情，并且愚蠢地决定在人力资源模块中加薪.
猜猜是什么?由于用户名"之外的孤立角色，新的约翰"立即成为经理.
因此，这是在决定利用或在这种情况下强制使用固有的，经过良好测试和已知的提供程序堆栈时必须注意的次要"警告.
我已经介绍了与之非常相似的场景，并提供了一个简单修改以消除此问题的概念证明此处.
或者，您可以简单地意识到这一点，并在删除用户时编写一些额外的代码来进行清理.
与实现自定义提供程序相比，这两种方法都更具吸引力.
干杯，祝你好运.
I have a single membership provider which is using the '/' default application name. I then have multiple applications which share this common membership provider configuration. Each application has it's own role provider configuration, they all share the same database as the membership provider but use a different application name to isolate their roles from each other.
When I create a member then a single user record is created and hence shared across all the applications. I then create specific roles unique to each application as they use a different application name.
The problem I am having is when I call Roles.AddUserToRole on a member who already exists. The roleprovider does not recognise the user as the application name context of the membership and role providers are different and it therefore proceeds to create a new user record for the application name that the role belongs to.
How can I prevent these duplicate user records from being created without sharing the application name between the membership and role providers?
The records are not actually 'duplicates'.
Understanding the relationship between the providers and the role of the aspnet_Users table may help clear this up.
First, understand that MembershipProvider and RoleProvider do not depend on one another, with a minor exception of some concern bleeding in the MembershipProvider.DeleteUser() method which I will explain later.
The role of Membership is to authenticate a user and, with the help of Authentication, protect access to your resources.
The role of Roles is to control access to resources by role assignment.
These are 2 seperate concerns and are not related, regardless of what the state of aspnet_Users may imply.
The salient issue is that the value that is used to connect all of the providers is username. The userid guid is similar and only one aspnet_users record is created for any username if all providers use the same application name because the first thing each provider does is check aspnet_users for a matching username and application name. If it finds one, it uses it, if not, it creates one and assigns a guid to the userid.
While it may appear that the userId guid is the 'global' identifier, this is not the case.
So, with a minor caveat - you can user separate role providers with a common membership store by using the same applicationname for each instance of membership and a different applicationname for each roles instance if you are aware of the issue related next.
The (really stupid) violation of the Seperation of Concerns that I mentioned earlier involves the actions taken by the SqlMembershipProvider when DeleteUser(deleteRelatedData) is called. It is then that SqlMembershipProvider acts as if it is the only dog in the fight, crosses over to roles and profiles to delete records using only it's keys and thus miss records that you expect to be gone.
Consider: (this is using the aforementioned setup of single membership, multiple roles)
You create user "John" with membership, assign him some roles with Roles. You now have to records in aspnet_users for John and everything works swimmingly. "John" is a manager and has appropriate high level roles assigned.
"John" becomes the 'fired guy' for some reason and is deleted via membership. As stated before, in our unique scenario, the membership records are deleted but the roles information remains.
A new "John" is hired to answer the phones and a membership user is created for him.
In his spare time, john explores the company intranet and can't believe how much cool stuff he can do and as a goof decides to give himself a raise in the HR module.
Guess what? new "John" is immediately a manager due to orphaned roles that are keyed off of "username".
So, that is the 'minor' caveat that you must be aware of when deciding to leverage, or in this case, coerce, the intrinsic, well tested and known provider stack.
I have already covered a scenario very similar to this and provide a proof of concept for a simple modification to eliminate this issue here and here .
Alternately, you can simply be aware of this and write some extra code to clean up when you delete a user.
Both of these are a far more attractive option than implementing custom providers.
Cheers and good luck.
这篇关于当使用具有不同应用程序名称的多个角色提供程序时，如何防止重复的成员身份用户?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
