Asp.net 表单认证值得学习吗？它是否可以用于具有大量流量的企业范围内的公司？

我知道这个问题有点模糊，但我需要知道为什么我工作过的大多数公司都没有使用它。我发现它非常有用（和会员资格一样）。我是不是遗漏了什么

是否使用Forms auth或windows auth在很大程度上取决于您的项目、其范围和用户群。 你的问题很广泛，所以我的回答也是。还要注意的是，这些都不是绝对的和高度主观的。 当使用库位于企业外部时，请使用Forms auth。 当您的公司拥有active directory且其用户群为内部用户时，请使用Windows auth。 如果您有一组特定的特权，并且基础架构人员不想添加100个用户组，请使用Forms auth。 如果存在其他内部应用程序并且您希望实现单点登录，请使用Windows auth。 如果希望对密码策略和用户注册进行更多控制，请使用forms auth。 如果您的企业使用IE，并且用户不希望被提示输入用户名/密码，请使用Windows auth

---

同样，高度主观的，仅仅因为你想要（例如）单点登录并不意味着你不能使用Forms auth。最后，这要看情况而定。

我很抱歉提出了这个广泛的问题。我指的不是Forms Auth vs Windows Auth（我知道并且已经实现了这两个），而是Forms Auth vs用于身份验证的定制代码（在单个应用程序中，跨服务器场等等）。我只是感到困惑，为什么我工作过的所有公司都创建了自定义代码，而他们本可以定制表单Auth来满足他们的需求。有安全问题吗？太难了吗？嗯……当你说他们编写了自定义代码时，他们还在使用会员资格提供者吗？MS将成员资格和角色提供者放在框架中是有原因的。我建议使用微软的开箱即用，因为它已经过测试。就我个人而言，我实现了自己的成员资格提供程序，源于它们的基本提供程序，因为我不喜欢存储我不使用的字段，如密码提示等。@Kant：来自自定义身份验证代码阵营，我的观点是，开箱即用的成员资格提供程序过于僵化，在大多数环境下无法工作，需要相同的时间（或更多）实现一个定制的成员资格提供者，它对你的数据存储库起作用，而不是使用你已经拥有的，特别是如果你已经有了自定义代码已经开发好的基础。谢谢。@杰伊我指的是完全自定义代码（与成员资格提供者分离，等等）。.谢谢@CheckRaise.我明白你的意思。