.Net 会员数据库是否可移植，或者帐户是否以某种方式绑定到原始网站或服务器？
我有一个 ASP.Net 网站，使用 .Net 会员资格和 SQL Server 提供程序，因此用户和角色存储在由 Aspnet_regsql.exe 创建的 SQL 表中。
该体系结构是否完全独立且可移植，或者其中的用户是否以某种方式绑定到他们创建帐户的特定网站？
换句话说，如果我们在dev或UAT中创建一堆用户，将这个数据库备份和恢复到另一台服务器上，在另一个域名下访问，它是否仍然可以正常工作？
当我们移动数据库时，我们看到一些奇怪的行为，例如用户失去组从属关系等，我很好奇这个数据库的可移植性和环境无关性到底如何。我偷偷怀疑某些东西与机器密钥或域绑定了。
I have an ASP.Net Web site using .Net Membership with a SQL Server provider, so the users and roles are stored in the SQL tables created by Aspnet_regsql.exe.
Is this architecture totally self-contained and portable, or are users in it somehow bound to the specific Web site on which they create their account?
Put another way, if we create a bunch of users in dev or UAT, the back up and restore this database to another server, accessed under another domain name, should it still work just fine?
We're seeing some odd behavior when we move the database, like users losing group affiliation and such, and I'm curious how portable and environment-agnostic this database really is. I have a sneaking suspicion that something is bound to the machine key or the domain.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，它们应该可以正常工作。
唯一需要小心的地方是密码管理。 .Net 会员提供商可能会使用计算机特定密钥来加密或散列密码。但是有一个解决方法，您可以告诉 ASP.NET 应用程序使用特定的计算机密钥，而不是自动生成的计算机特定密钥。
在我的应用程序中，我对密码进行加密，并指定了我的机器密钥，如下所示用于加密/解密。当我这样做时，我可以将我的开发数据库移植到生产服务器，或者也可以非常轻松地将数据库从一台生产服务器迁移到另一台生产服务器。
在与 MembershipProviders 合作时，您无需担心有关迁移的任何其他问题。
Yes they should work fine.
Only place where you need to be careful is password management. .Net membership providers may use machine specific keys to encrypt or hash the passwords. But there's a work-around where in you tell the asp.net application to use specific machine key and not the auto-generated machine specific keys.
In my application, I keep my passwords encrypted and I have specified my machine-key as below for encryption/decryption. When I do this, I can port my development database to production server or also migrate database from one production server to another very much easily.
There's nothing else you need to worry about regarding migration while working with MembershipProviders.
用户与应用程序名称绑定。您可以检查它并查看每个用户链接到的应用程序名称是否与生产服务器上的 web.config 上的应用程序名称相对应。
除此之外，当您将成员资格移植到另一个数据库时，您应该确保您不仅获取表，还获取所有存储过程。如果出于任何原因，您只是移植数据库架构，则应在移植之前运行 Aspnet_regsql.exe。
The users are bound to the application name. You could check it and see if the application name each user is linked to corresponds to the application name on the web.config on your production server.
Apart from that, when you are porting membership to another database, you should make sure that you are taking not only tables but all the stored procedures as well. If, for any reason, you are just porting your database schema, you should run Aspnet_regsql.exe before you port it.