使用会员 API 的主要缺点是什么？
使用会员 API 的主要缺点是什么？我什么时候应该考虑依赖手动编码？
Whats are the major disadvantages of using Membership API? And when should i consider relying on using manual coding?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
永远不要为任何与安全相关的事情编写自己的代码。这包括身份验证/成员身份。
编写自己的身份验证系统看似简单：基本功能易于编写和测试。然而，这里的问题是设计过程的安全性。因为它很容易做到，所以也很容易构建一些似乎工作的东西 - 它通过了你所有的测试，允许那些它应该做的，不允许那些不该做的，所以你部署您的系统。然后，一位黑客发现了您设计中的小缺陷。一年后，你终于发现自己被破解了。
会员 API 的特点是它是可扩展的。如果没有一个开箱即用的提供程序可以满足您的需要，您可以扩展一个提供程序，而不必从头开始，所以这确实是非常例外的情况，会阻止您使用它。
此原则不仅适用于 ASP.Net，还适用于您可能想要实现身份验证系统的任何其他平台。无论您拥有什么平台，请始终尽可能地利用为您提供的经过实战检验的安全功能。
NEVER write your own code for anything to do with security. This includes authentication/membership.
Writing your own authentication system is deceptively easy: the basic functionally is simple to write and test. However, the problem here is designing the process to be secure. Because it's easy to do, it's also very easy to build something that only seems to work — it passes all your tests, allows those it's supposed to and does not allow those it isn't, and so you deploy your system. Then along comes a hacker and finds that little flaw in your design. A year later you finally find out you've been cracked.
The thing about the membership API is that it's extensible. If there's not an out-of-the-box provider that does what you need you can extend one without having to start from scratch, so it would be pretty exception circumstances indeed that prevent you from using it.
This principle applies not only to ASP.Net, but also to any other platform where you might want to implement an authentication system. Whatever platform you have, always lean as much as possible one the battle-tested security features provided to you.