我刚刚发现ASP.net使用自己的个人资料系统来注册用户，并且似乎有很多功能可用作奖励（例如安全身份验证）。然而，对于通用开发环境而言，如果没有我真正了解如何（如用户数据的存储位置）让我感到害怕，那么在后台工作的情况看起来非常具体。 p>
是否值得开发一个需要使用asp.net配置文件系统进行用户身份验证的网站，还是更好地开发自己的SQL数据库等？我无论如何都不会避免使用SQL，即使我使用配置文件，我也会使用配置文件唯一ID来识别SQL表中的用户数据，因此从这个意义上讲，我不会完全避免使用SQL来获取用户信息。
我最喜欢的配置文件是你可以使用它们在Web.config文件中创建自定义权限（），并避免在所有aspx源文件的顶部输入相同的代码来进行身份验证检查。
我喜欢它的另一件事是安全性内置了安全的身份验证cookie，因此我不必自己处理它们。
但它似乎 真的很重要。我只是对ASP.Net开发的内容以及它们旨在实现的目标感到困惑。
答案 0 :(得分：4)
Profile / Membership和Role provider API非常交织，并且指定的内容非常狭窄。好处是你不需要做很多功能就可以了。缺点是当您需要的东西与提供的东西不匹配时。尽管如此，API还是有许多潜在的问题需要解决，使用它确实很有意义，至少在身份验证方面是这样。
我的需求与API提供的内容不匹配，我真的只需要会员资格部分。问题是，我需要在Web应用程序和桌面应用程序中使用相同的身份验证和授权。我的需求非常独特，但它专为课堂设置而设计。
让会员资格满足我的需求并不困难。我只需要实现Membership API。有些功能，我只是不需要使用会员资格API，如自我注册等。当然，这确实给我带来了角色管理的挑战。通常，只要您的用户对象实现IPrinciple，就可以直接使用它 - 但如果您的用户类未在同一程序集中定义，则开发Web服务器Visual Studio程序包会出现序列化问题。这些问题涉及序列化，您的选择包括将对象放在GAC中或使用GAC中的对象（如GenericPrincipal和GenericIdentity）自行处理跨appdomain序列化。后一种选择就是我必须做的事情。
最重要的是，如果你不介意让API为你做所有的管理，那么它就可以正常工作了。这是一项聪明的工程工作，并试图迫使你走上一条具有良好安全实践的路线。我已经使用了许多不同的身份验证/授权API（大多数不是基于CLR的），并且API确实感觉有点限制。但是，如果您想避免会话/状态/缓存管理的陷阱，您确实需要使用API并根据需要插入您自己的提供程序。
使用您的数据库，如果您需要将用户链接到任何数据库元素，您将存储用户的登录ID（Context.User.Identity.Name）。
答案 1 :(得分：3)
您似乎混合了个人资料/成员资格/角色提供程序API。但要回答你的问题：为什么不使用它？我会使用它，除非有一个真正的约束使它无法使用......