使用表单身份验证将用户链接到配置文件
我正在将旧版 winform 应用程序移至网络，并希望获得有关表单身份验证的一些建议。 我是否正确地假设表单身份验证比汇总我自己的用户身份验证功能更好？
自己动手很容易，因为这就是 winform 应用程序所做的，并且表结构已经支持它，但表单身份验证看起来可以更好地保护站点和用户身份验证信息。
我是一名老程序员，但在 Web 开发领域还很年轻，多年来我了解到，使用 MS 内置工具有时看起来比实际效果更好......表单身份验证不是其中之一，不是吗？
谢谢！
I am moving a legacy winform app to the web and would like some advice on forms authentication. Am I correct in assuming that forms authentication is better than rolling up my own user authentication functionality?
It would be easy enough to roll my own since the this is what the winform application did and the table structure already supports it, but forms authentication looks like it would do a much better job securing the site and the user authentication info.
I'm an old programmer, but pretty young in web dev and I have learned over the years that using MS built in tools sometimes looks better than it works...forms authentication isn't one of those cases is it?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我想说的是，表单身份验证是您可能不会遇到“买家悔恨”的情况。 您可以选择使用一些非常好的功能。 该模型非常灵活，因为它允许您实现您自己的会员提供程序。
I'd say that Forms Authentication is a case where you're likely to experience no "buyers remorse". You can opt in to use some pretty nice features. The model is very flexible because it allows you to implement your own Membership Providers.
使用表单身份验证并不意味着您不能使用这些表。 您将检查用户名/密码，并告诉 asp.net 用户已通过身份验证。 Asp.net 将从那里继续，确保识别和验证来自该用户的进一步请求（基于身份验证票证）。
更新 1： 后来，asp.net 包含了成员资格提供程序，并对其进行了一些控制。 即使如此，您仍然可以实现自己的会员资格提供程序，在非常简单的情况下，您可以通过仅实现 1 或 2 个方法来完成。 如果您有多个功能，并且它们与会员提供商支持的功能不能很好地映射，那么我会坚持使用自定义实现。
Using forms authentication doesn't means you don't get to use those tables. You will do the check for username/password, and tell asp.net that the user is authenticated. Asp.net will continue from there, ensuring further requests from that user are identified and authenticated (based on an authentication ticket).
Update 1: Later on asp.net included membership providers, with some controls for it. Even then you can still implement your own membership provider, which in really simple cases you can do by implementing only 1 or 2 of the methods. If you have several features, and they don't map well with what the membership provider supports, I would stick to a custom implementation.