我刚刚发现 ASP.net 使用自己的配置文件系统来注册用户，并且似乎有很多可用的功能(例如安全身份验证)。然而，对于通用开发环境来说，拥有这样一个功能似乎相当具体，而且在后台工作的方式就像配置文件系统所做的那样，而我并不真正知道如何(比如用户数据存储在哪里)有点让我害怕。
是否值得开发一个需要使用 asp.net 配置文件系统进行用户身份验证的网站，还是使用 SQL 数据库等开发自己的网站会更好？无论如何，我不会避免使用 SQL，即使我使用配置文件，我也会使用配置文件的唯一 ID 来标识 SQL 表中的用户数据，因此从这个意义上说，我根本不会避免使用 SQL 来获取用户信息.
关于配置文件，我最喜欢的一点是，您可以使用它们 () 在 Web.config 文件中创建自定义权限，并避免必须在所有 aspx 源文件的顶部键入相同的代码来进行身份验证检查。
我喜欢它的另一件事是，安全性是通过安全身份验证 cookie 内置的，因此我不必自己处理它们。
但这似乎并不是什么大不了的事情。我只是对 ASP.Net 开发的配置文件的立场以及它们的设计目的感到困惑。
最佳答案
配置文件/成员资格和角色提供者 API 非常相互交织，并且指定的内容非常狭窄。好处是您几乎不需要做任何事情就可以让很多功能正常工作。缺点是当您需要的与所提供的不匹配时。然而，API 会为您解决许多潜在的问题，使用它确实有意义，至少对于身份验证而言。
我的需求与 API 提供的不匹配，我实际上只需要成员(member)部分。问题是我有一个部分需要在 Web 应用程序和桌面应用程序中使用相同的身份验证和授权。我的需求非常独特，但它是为类环境设计的。
让成员(member)资格满足我的需求并不那么困难。我只需要实现成员(member) API。有几个功能是我不需要成员(member) API 的，比如自助注册等。当然，这确实给我带来了角色管理的挑战。通常，只要您的用户对象实现 IPrinciple，就可以直接使用它，但如果您的用户类未在同一程序集中定义，则开发 Web 服务器 Visual Studio 包会出现序列化问题。这些问题涉及序列化，您的选择包括将对象放入 GAC 中，或者使用 GAC 中的对象(例如 GenericPrincipal 和 GenericIdentity)自行处理跨应用程序域序列化。后一个选择是我必须做的。
底线是，如果您不介意让 API 为您完成所有管理，那么它就可以正常工作。这是一项聪明的工程工作，并试图迫使您采取适当的安全实践。我使用过许多不同的身份验证/授权 API(大多数不是基于 CLR)，并且这些 API 确实感觉有点受限。但是，如果您想避免 session /状态/缓存管理的陷阱，您确实需要使用 API 并根据需要插入您自己的提供程序。
对于数据库，如果您需要将用户与任何数据库元素链接，您将存储用户的登录 ID (Context.User.Identity.Name)。
关于asp.net - 值得使用 ASP.Net 内置的配置文件系统吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4014258/