值得使用ASP.Net内置配置文件系统吗？

Question

我刚刚发现ASP.net使用自己的配置文件系统来注册用户，并且似乎有很多可用的特性（如安全认证）。然而，对于通用开发环境而言，具有这样的功能似乎相当具体，而在配置文件系统的背景下工作的东西却没有真正知道如何（像存储用户数据的地方）那样让我害怕。

是否值得开发一个网站，使用asp.net配置文件系统，需要用户认证，或者会更好地发展自己的使用SQL数据库等？即使我使用配置文件，我也不会避免使用SQL，我将使用配置文件唯一标识来标识SQL表中的用户数据，所以从这个意义上说，我不会避免使用SQL来完成用户信息。

我最喜欢关于配置文件的事情是，您可以使用它们（）在Web.config文件中创建自定义权限，并避免必须在所有aspx源文件的顶部键入相同的代码来执行身份验证检查。

其他的事情，我挺喜欢它是安全性是建立在安全的身份验证Cookie，所以我不会有对付他们自己。

但它似乎并不像是什么大不了的事真。对于配置文件在ASP.Net开发中所处的位置以及它们旨在实现的目标，我只是感到困惑。

Answer 1

的资料/成员资格和角色提供API非常交织在一起，并指定东西很狭窄，我会用它。好处是，你不得不做很多功能的工作。缺点是当你需要什么不符合提供的。尽管如此，API还是有很多潜在的障碍，至少对于身份验证来说，使用它确实是有意义的。

我的需求与API提供的不匹配，我真的只需要Membership部分。问题是我有一块需要在Web应用程序和桌面应用程序中使用相同的身份验证和授权。我的需求非常独特，但它是为课堂设置而设计的。

获得会员资格以满足我的需求并不困难。我只需要实现Membership API。有些功能我不需要使用Membership API，比如自我注册等。当然这给我带来了角色管理的挑战。通常情况下，只要用户对象实现了IPrinciple，它就可以直接使用 - 但是如果您的用户类没有在同一个程序集中定义，那么开发Web服务器Visual Studio包会出现序列化问题。这些问题涉及序列化，您的选择包括将对象放入GAC中，或者使用GAC中的对象（如GenericPrincipal和GenericIdentity）自己处理跨应用程序域序列化。后一种选择是我必须做的。

底线是，如果你不介意让API完成所有的管理你的，比它会工作得很好。这是一个聪明的工程工作，并试图强制你采用体面的安全措施。我已经使用了许多不同的认证/授权API（大多数不是基于CLR的），并且API确实感觉有点受限。但是，如果您想通过会话/状态/缓存管理避免陷阱，那么您确实需要使用该API并根据需要插入自己的提供程序。

与您的数据库，如果你需要用户与你会存储用户的登录ID（Context.User.Identity.Name）的任何数据库元素联系起来。

Answer 2

您似乎混合配置文件/成员资格/角色提供程序API。但要回答你的问题：为什么不使用它？除非有真正的约束，使得它无法使用...