代码之家  ›  专栏  ›  技术社区  ›  James McMahon

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

  •  1
  • James McMahon  · 技术社区  · 15 年前

    (注: these two 问题是相似的,但更具体的是ASP.NET)

    考虑一个典型的Web应用程序,它有一个富客户机(在我的例子中是flex),其中有一个表单,一个将表单的输入映射到数据模型的底层客户机逻辑,一些将这些对象远程处理到服务器逻辑的方法,通常将其放在数据库中。

    一般来说,我应该把验证逻辑放在哪里,即确保电子邮件地址、数字等的格式正确?

    1. 越早越好。像flex这样的富客户机框架提供了内置的验证器逻辑,允许您在表单提交时,甚至在表单到达数据模型之前进行验证。这是一个很好且响应迅速的方法,但是如果您开发了一些可扩展的东西,并且您希望验证能够避免以后的贡献者的编程错误,那么这就不可能理解它。
    2. 在客户端的数据模型上。因为这是数据的“官方”表示,并且您已经有了数据类型和getter/setter,所以这个验证从扩展系统的人员那里捕获用户错误和编程错误。
    3. 在服务器上接收数据时。这增加了对可能稍后加入系统的损坏或恶意客户端的保护。在多客户机场景中,这也为您提供了一个授权验证源。
    4. 就在您将数据存储到后端之前。这包括防止在链中任何地方发生的所有错误(存储逻辑本身除外),但可能需要一路将错误冒泡。

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

    4 回复  |  直到 15 年前
        1
  •  1
  •   coobird    15 年前

    在不太具体的情况下,我认为应该基于以下原因进行验证:

    1. 让用户知道输入在某种程度上不正确。
    2. 保护系统免受攻击。

    提前让用户知道某些数据不正确是很友好的——例如,电子邮件输入字段可能有红色背景,直到 @ 签名并输入域名。只有当电子邮件地址遵循RFC 5321/5322中的格式时,电子邮件字段才应该变绿,并可能打上一个很好的复选标记,让用户知道电子邮件地址看起来不错。

    另外,让用户知道所提供的信息在某种程度上可能不正确也会有所帮助。例如,询问用户他或她是否真的打算让同一个收件人在同一封电子邮件中接受两次。

    然后,接下来应该是在服务器端进行检查——不要假设通过的数据是格式良好的。执行检查以确保数据正确,并注意任何攻击。

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

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

    我想从我的角度来看,友好和防御性才是关键。

        2
  •  1
  •   JohnIdol    15 年前

    只有一条规则在使用 至少 某种类型的 服务器验证 总是(列表中的数字3/4)。

    客户端验证 (数字2/1)使用户体验更为迅速,并减少了负载(因为您不向服务器发布那些不通过客户端验证的内容)。

    需要指出的一件重要的事情是,如果只进行客户端验证,那么您将面临很大的风险(想象一下,如果您的客户端验证依赖于javascript,并且用户在浏览器上禁用了javascript)。

        3
  •  0
  •   Vatine    15 年前

    服务器端肯定有验证。我认为应该尽早在服务器端进行验证,这样恶意(或不正确)数据进入系统的可能性就小了。

    客户端的输入验证很有帮助,因为它使接口更为快捷,但是不能保证进入服务器的数据已经通过了客户端验证,所以必须在服务器端进行验证。

        4
  •  0
  •   buddy    15 年前

    由于安全性,方便:服务器端和尽早 但同样重要的是要进行一些全局模型/业务逻辑验证,因此,当您有多个具有公共数据的表单(例如产品名称)时,验证规则应该保持一致,除非需求另有说明。