实用的用户验证（敏感性和特异性）？

Question

实用的用户验证（敏感性和特异性）？

5

当我刚学习使用正则表达式时，我们被教授如何解析诸如电话号码（显然总是5位数字、一个可选空格和另外6个数字），电子邮件地址（显然总是字母数字，然后是单个“@”，接着是字母数字后跟一个“.”和三个字母），这些都应该用来验证用户输入的数据。当然，随着我的发展，我已经学会了基本方法的愚蠢之处，但是我越看，就越质疑整个概念，即使通过正则表达式进行最开放、小心和正确的电子邮件地址验证，也需要数百甚至数千个字符，以便同时接受所有合法情况并正确地拒绝非法情况。更糟糕的是，所有这些努力对实际有效性一无所用，用户可能会意外添加一个“a”，或者根本不使用该电子邮件地址，甚至在使用其他人的地址，或者甚至使用一个被不适当标记的“+”符号。然而与此同时，似乎我遇到的每个网站仍在进行这种技术检查，阻止我在电子邮件地址或名称中输入更加模糊的字符，或者反对某人拥有多个或少于一个标题、一个名字和一个姓氏，所有这些都是纯拉丁字符制成的，但没有任何形式的检查以确保它是我的真实姓名。这是否有益呢？一旦处理了注入攻击（应通过除消毒输入外的其他方法来处理），这些检查还有其他用途吗？另一方面，是否有一种确切的方法来验证用户详细信息，而不是在上下文中“使用”它们并查看是否失败？

- Cactus

2个回答

0

这些检查还有其他的意义吗？

当然有。知道你的数据是否有效非常重要。例如，对于电子邮件地址，在发送未经验证的地址的电子邮件时，至少会导致反弹。如果反弹够多，你的邮件主机可能会将你阻止以避免垃圾邮件。如果不验证电话号码，则可能会导致不必要的成本，因为你的应用程序尝试向它们发送短信。如此等等。

另一方面，实际上是否有一种肯定的方法来验证用户详细信息，而不是在使用它们的任何方式使得上下文合理，并看看它是否失效呢？

是的，但正则表达式通常不是验证数据的好方法。如果一个电话号码应该是“5位数字+1个空格+6位数字”，那么如果我输入“5位数字+2个空格+6位数字”或“5位数字+1个破折号+6位数字”或“11位数字”的话，你的验证就会失败。运用常识，预期用户提供任何疯狂的格式。了解最低限度的绝对要求。例如，如果你需要总共11位数字，则首先去除所有非数字内容。然后格式不重要。

此外，也请阅读RFCs。我无法计算有多少次我的电子邮件地址因为其中有加号而被拒绝。其中有很多大型面向技术的公司，他们的程序员应该知道得更好，这让人非常失望。

- Alex Howansky

我所询问的是“知道你的数据是有效的”，知道电子邮件地址符合RFC标准并不能阻止来自该地址的反弹，如果它实际上不存在或是一次性的丢弃。使用电话号码正则表达式甚至进行基本的错误代码处理也会变得非常庞大，并在几个月后变得不准确。你认为验证数据的好方法是什么？ - Cactus

当然，你无法阻止不存在的地址反弹。(这就是为什么你需要一个反弹处理器来捕捉它们并防止它们再次发生。) 然而，检查输入的地址是否语法无效肯定不是浪费时间，只要你知道正确的有效语法是什么。例如，“后跟一个'.'和三个字母”是错误的。问题不在于你是否应该验证——你应该验证。问题是，到什么程度？对于你的使用，仅检查电话号码是否有非空值可能已经足够了。从小处开始。 - Alex Howansky

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- deceze · Accepted Answer

过度验证是互联网的祸害之一。特别是如果编写验证代码的人对问题领域没有实际知识。不，你可能实际上不知道电子邮件地址的有效语法。或者真实世界的地址，特别是国际地址。或者电话号码。又或者人名。

看一些本地化的例子（我的电子邮件地址），并推断出覆盖领域内所有可能值的规则（所有电子邮件地址）是疯狂的。除非你有完美的领域知识，否则不应该制定关于该领域的规则。在电子邮件地址的情况下，这导致只有一个非常狭窄的可能的电子邮件地址子集实际上可以在日常生活中使用。谢谢你们。

关于人名，无论一个人告诉你他们的名字是什么，按定义来说就是他们的名字。这是你称呼他们的方式。你不能自动验证它；他们必须提供出生证明副本以进行实际官方验证。即使如此，这真的是你感兴趣知道的吗？或者你只需要一个“句柄”在论坛页面上问候和识别他们？

Facebook（现在还是过去）对姓名进行严格验证，以强制人们使用真实姓名注册。嗯，我在Facebook上认识的很多人仍然使用一些虚构的荒谬名字。过滤器显然不起作用。话虽如此，也许它对于Facebook来说足够好了，因为大多数人都使用自己的真实姓名，因为他们懒得弄清楚哪种特定模式会通过验证。从这个意义上说，这样的过滤器可以发挥一些作用。

最终，由你决定验证原因和你想要执行的具体限制。问题在于，人们在编写验证代码之前经常没有考虑到更大的局面，并且对其特定限制没有充分理由。不要陷入这个陷阱。