ASP.NET MVC 用户身份验证 - 为什么它应该如此复杂？
我正在尝试在我的新项目中使用 ASP.NET MVC，并且预计用户身份验证应该相当简单。我的目标是在我的主数据库中有一个单独的用户数据库表。
我认为 SqlTableProfileProvider 应该是解决方案。所以我将相应的表添加到我的数据库中并更改了 web.config 文件。但似乎无论我在那里进行什么更改，我的 Web 应用程序仍然使用默认身份验证（通过 ASPNETDB.mdf 文件）。
可能是什么问题？
（我的 web.config 文件开头是：）
I'm trying to use ASP.NET MVC to my new project and have been expected that the user authentication should be rather simple there. My goal is to have a separate user database table in my main database.
I thought that the SqlTableProfileProvider should be the solution. So I added the corresponding table into my database and changed the web.config file. But it seems no matter what I change there, my web application still using the default authentication (via ASPNETDB.mdf file).
What could be the problem?
(my web.config file beginning is:)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请参阅此参考，了解如何创建标准应用程序服务表和关联的SQL Server 数据库中的数据库实体。完成后，更改 web.config 文件中的默认应用程序服务连接字符串以使用成员资格、角色和配置文件的内置提供程序应该是一件简单的事情。
See this reference on how to create the standard application services tables and associated database entities in your SQL server database. Once done it should be a simple matter of changing the default Application Services connection string in the web.config file to use the built-in providers for membership, roles, and profiles.
做我所做的事情，忘记滚动您自己的会员资格提供程序等或使用 sqltableprofileprovider - 相反，通过与您自己的表的关系来扩展默认会员资格添加的表，其中包含您想要存储的额外数据。
因此，例如，向数据库中添加另一个名为“Details”的表，然后将主键设置为与 aspnet_Users 表的主键 1 对 1 相关。像使用其他表一样使用这个新表。当您想要用户的主键时，请使用membership api 来获取它。
未测试！
然后将所需的数据添加到详细信息表和集合中。
对我来说似乎更灵活 - 尽管我可能做错了！ :)
Do what I do and forget about rolling your own membership provider etc or using sqltableprofileprovider - instead extend the tables that the default membership adds through relations to your own table(s) which contains the extra data you want to store.
So, add another table to your database called 'Details', for example, then set the primary key to be related 1 to 1 to the primary key of the aspnet_Users table. Use this new table as you would any other. When you want the primary key of a user, use the membership api to grab it.
not tested!
Then add the data you require to your details table and your set.
Just seems more flexible to me - although I'm probably doing it all wrong! :)