输入数据验证的正确位置是什么？

Question

（注意：thesetwo 问题类似，但更具体到 ASP.Net）

考虑一个带有富客户端（在我的例子中是 Flex）的典型 Web 应用程序，其中有一个表单，一个将表单输入映射到数据模型的底层客户端逻辑，以及将这些对象远程处理到服务器逻辑的某种方式，通常将其放入数据库中。

我应该在哪里 - 一般而言 - 将验证逻辑放在哪里，i。 e.确保电子邮件地址、数字等格式正确？

1. 尽可能早。像 Flex 这样的富客户端框架提供了内置的验证器逻辑，让您可以在表单提交时进行验证，甚至在它到达您的数据模型之前。这很好而且响应迅速，但如果您开发了一些可扩展的东西，并且您希望验证以防止后来的贡献者出现编程错误，那么这不会捕获它。
2. 在客户端的数据模型中。由于这是您的数据的“官方”表示，并且您已经拥有数据类型和 getter/setter，因此此验证会捕获来自扩展您系统的人员的用户错误和编程错误。
3. 在服务器上收到数据后。这增加了对以后可能加入系统的损坏或恶意客户端的保护。同样在多客户端场景中，这为您提供了一种权威的验证来源。
4. 就在您将数据存储到后端之前。这包括防止链中任何地方出现的所有错误（存储逻辑本身除外），但可能需要将错误一直冒泡。

我有点倾向于同时使用 2 和 4，因为我正在构建一个具有第三方潜在扩展点的应用程序。除了 4 之外使用 2 似乎是多余的，但我认为它使客户端应用程序的行为更加用户友好，因为它不需要往返服务器来查看数据是否正常。你的方法是什么？

Answer 1

不用太具体，我认为应该进行验证，原因如下：

1. 让用户知道输入在某些方面不正确。
2. 保护系统免受攻击。

尽早让用户知道某些数据不正确会很友好——例如，在@ 符号和域名输入之前，电子邮件输入字段可能具有红色背景。只有当电子邮件地址符合 RFC 5321/5322 中的格式时，电子邮件字段才会变为绿色，并且可能会打上一个漂亮的复选标记，让用户知道电子邮件地址看起来不错。

此外，让用户知道所提供的信息在某些方面可能不正确也会很有帮助。例如，询问用户他或她是否真的打算为同一封电子邮件让同一收件人两次。

然后，接下来应该在服务器端进行检查——永远不要假设传入的数据格式正确。执行检查以确保数据可靠，并提防任何攻击。

假设客户端会阻止 SQL 注入，并且盲目地接受来自与服务器的连接的数据可能是一个严重的漏洞。如前所述，如果服务器过于信任，其唯一目的是攻击系统的恶意客户端很容易破坏系统。

最后，执行任何检查以查看数据是否正确，并且逻辑可以正确处理数据。如果有任何问题，请通知用户任何问题。

我想，从我的角度来看，友好和防御就是归根结底。

Answer 2

只有一条规则始终使用至少某种服务器验证（列表中的第 3/4 位）。

客户端验证（第 2/1 号）使用户体验更快捷并减少负载（因为您不会将未通过客户端验证的内容发布到服务器）。

需要指出的重要一点是，如果您只进行客户端验证，那么您将面临巨大风险（想象一下，如果您的客户端验证依赖于 javascript，而用户在他们的浏览器上禁用了 javascript）。

Answer 3

肯定应该在服务器端进行验证。我认为应该尽早在服务器端进行验证，这样恶意（或不正确）数据进入系统的机会就会减少。

客户端的输入验证很有帮助，因为它使界面更快捷，但不能保证进入服务器的数据已经通过客户端验证，因此必须在服务器端进行验证。

Answer 4

因为安全又方便：服务器端和越早越好 但同样重要的是进行一些全局模型/业务逻辑验证，因此当您有多个具有公共数据（例如产品名称）的表单时，验证规则应保持一致，除非要求另有说明。