将用户从自定义表迁移到 ASP.NET 成员资格表
我正在创建一个新的中间层，我们所有的客户端调用都将通过 WCF 服务。我们在服务中使用 ASP.NET 成员身份来验证用户身份。中间层将访问现有数据库，其中我们已经有一个包含用户名和密码的 InetUsers 表。
这就是事情开始变得混乱的地方。这个新的中间层将由我们的 Web 应用程序使用，但不会由我们现有的桌面应用程序使用，在我们将来某个时候重写它之前，桌面应用程序将使用旧的 COM+ 中间层。 Web 应用程序的用户管理在桌面应用程序中进行。换句话说，将在桌面应用程序中创建用户并设置和更改密码，这反过来又会访问已经存在的 InetUsers 表。
理想情况下，当我们部署新的中间层时，我们将从 InetUsers 表中获取所有用户，并在 aspnet_Users 和 aspnet_Membership 中为他们创建记录。然后，我们将在 InetUsers 表上设置一个触发器，以使 aspnet_Users 和 aspnet_Membership 保持最新。
这里面包含了一大堆问题，所以我会尝试在这里列出所有问题：
- 这是正确的方法吗？显然，将这些数据放在两个地方并不理想，但请记住，我不是这里的最终决策者，而且我们在这里有点坚持一些遗留的东西，至少现在是这样。不过——也许还有更好的方法。
- 同样，我们最好编写自己的会员资格提供程序而不是使用 SqlMembershipProvider 吗？这样做有多困难/容易？
- 如果我们使用这种方法，我计划使用 aspnet_Membership_XXXX 存储过程来初始填充表以及触发器。对此进行了一些研究，看来如果我想直接从 SQL 调用 aspnet_Membership_CreateUser （即在触发器中......）而不是使用 API，我必须存储明文密码，因为我无法获取盐和否则哈希值正确。这是真的吗？
- 这些是否有意义，或者我一开始就采取了错误的方式？
非常感谢所提供的任何帮助。
I'm creating a new middle tier where all of our client calls will go through a WCF service. We're using ASP.NET membership with the service in order to authenticate users. The middle tier will be hitting an existing database in which we already have an InetUsers table containing usernames and passwords.
This is where it starts to get messy. This new middle tier will be used by our web application, but not by our existing desktop application, which will - until we rewrite it at some point in the future - be using the old COM+ middle tier. Administration of the users for the web application takes place in the desktop application. In other words, users will be created and passwords set and changed from within the desktop application, which in turn hits the already existing InetUsers table.
Ideally, what will happen is when we deploy the new middle tier, we'll take all of the users from the InetUsers table and create records for them in aspnet_Users and aspnet_Membership. Then we'll set a trigger on the InetUsers table to keep aspnet_Users and aspnet_Membership up-to-date.
There's a whole bunch of questions wrapped up in this, so I'll try and list them all out here:
- Is this the right approach? Obviously having this data in two places isn't ideal, but bear in mind here that I'm not the final decision maker here and we're kinda stuck with some legacy stuff here, at least for now. Still - maybe there's a better way.
- In the same vein - would we be better off coding our own membership provider rather than using the SqlMembershipProvider? How difficult/easy is it to do so?
- If we use this approach, I plan on using the aspnet_Membership_XXXX stored procedures for the initial population of the tables as well as in the triggers. Having done some research into this, it appears that if I want to call aspnet_Membership_CreateUser directly from SQL (ie in a trigger...) rather than using the API, I have to store clear text passwords since I can't get the salt and the hash right otherwise. Is this true?
- Does any of this even make sense or am I going about this the wrong way to begin with?
Much appreciation for any help offered.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您已经有一个数据库结构，我将编写一个自定义成员资格提供程序并跳过现有的成员资格结构。这样，您就可以使用开发人员已经习惯的一种数据库结构，无论是用于数据访问、报告还是其他目的。创建一个继承自 MembershipProvider 的类。看看这个：http://msdn.microsoft.com/en-us/library /f1kyba5e.aspx 或 http://www.devx。 com/asp/Article/29256/0/page/3。
您只需要实现您实际需要的功能。
If you already have a database structure, I would write a custom membership provider and skip the existing membership structure. That way you are using one database structure that the developers are already used to, whether for data access, reporting, or other purposes. Create a class that inherits from MembershipProvider. Check this out: http://msdn.microsoft.com/en-us/library/f1kyba5e.aspx or http://www.devx.com/asp/Article/29256/0/page/3.
You only need to implement the features you actually need.
编写自己的会员资格提供程序并不“困难”。如果您计划使用混合解决方案一段时间，那么推出自己的提供程序可能比在两个地方维护数据更干净。
然后，当您准备好迁移到新的标准会员资格提供商时，只需将用户转移一次并重新指向桌面和 Web 界面的新提供商即可。
It isn't "difficult" to code your own membership provider. If you're planning on living with the hybrid solution for a while, it would probably be cleaner to roll your own provider than maintain the data in two places.
Then, when you're ready to move to the new, standard, membership provider, it should just be a matter of transfering the users over once and re-pointing to the new provider for both the desktop and web interfaces.