JavaScript：客户端与服务器端验证

正如其他人所说的那样你应该两个都做。原因如下：

As others have said, you should do both. Here's why:

您希望首先在客户端验证输入，因为您可以提供更好的反馈给普通用户。例如，如果他们输入无效的电子邮件地址并移至下一个字段，则可以立即显示错误消息。这样，用户可以在提交表单

You want to validate input on the client side first because you can give better feedback to the average user. For example, if they enter an invalid email address and move to the next field, you can show an error message immediately. That way the user can correct every field before they submit the form.

如果您只在服务器上验证，则必须提交表单，收到错误消息，并尝试寻找问题。

If you only validate on the server, they have to submit the form, get an error message, and try to hunt down the problem.

（通过让服务器在填写用户原始输入的情况下重新呈现表单可以缓解这种痛苦，但客户端验证仍然更快。）

(This pain can be eased by having the server re-render the form with the user's original input filled in, but client-side validation is still faster.)

您希望在服务器端进行验证，因为您可以防范恶意用户，谁可以轻松绕过您的JavaScript并向服务器提交危险的输入。

You want to validate on the server side because you can protect against the malicious user, who can easily bypass your JavaScript and submit dangerous input to the server.

信任您的UI非常危险。 他们不仅可以滥用您的用户界面，而且可能根本不使用您的用户界面，甚至是浏览器。如果用户手动编辑URL，或运行自己的Javascript，或使用其他工具调整HTTP请求，该怎么办？如果他们从 curl 或从脚本发送自定义HTTP请求怎么办？

It is very dangerous to trust your UI. Not only can they abuse your UI, but they may not be using your UI at all, or even a browser. What if the user manually edits the URL, or runs their own Javascript, or tweaks their HTTP requests with another tool? What if they send custom HTTP requests from curl or from a script, for example?

（ This不是理论上的;例如，我在一个旅行搜索引擎上工作，通过发送 POST 请求将用户的搜索重新提交给许多航空公司，公交公司等，就像用户一样填写了每个公司的搜索表单，然后收集并整理了所有结果。这些公司的表单JS从未执行过，对我们来说，它们在返回的HTML中提供错误消息是至关重要的。当然，API会很好，但这就是我们必须做的事情。）

(This is not theoretical; eg, I worked on a travel search engine that re-submitted the user's search to many airlines, bus companies, etc, by sending POST requests as if the user had filled each company's search form, then gathered and sorted all the results. Those companies' form JS was never executed, and it was crucial for us that they provide error messages in the returned HTML. Of course, an API would have been nice, but this was what we had to do.)

不允许这样做不仅从安全的角度来看是天真的，而且也是非标准的：客户应该被允许以他们希望的任何方式发送HTTP，你应该正确回应。这包括验证。

Not allowing for that is not only naive from a security standpoint, but also non-standard: a client should be allowed to send HTTP by whatever means they wish, and you should respond correctly. That includes validation.

服务器端验证对于兼容性也很重要 - 并非所有用户，即使他们使用的是浏览器，也会有已启用JavaScript。

Server side validation is also important for compatibility - not all users, even if they're using a browser, will have JavaScript enabled.

有些验证甚至不能在服务器端应用程序代码中正确完成，在客户端代码中完全不可能，因为它们依赖于数据库的当前状态。例如，其他人没有注册该用户名，或您评论的博客文章仍然存在，或没有现有预订与您请求的日期重叠，或者您的帐户余额仍然足以涵盖该购买。 只有数据库才能可靠地验证依赖于相关数据的数据。开发人员经常搞砸，但 PostgreSQL提供了一些好处解决方案。

There are some validations that can't even be properly done in server-side application code, and are utterly impossible in client-side code, because they depend on the current state of the database. For example, "nobody else has registered that username", or "the blog post you're commenting on still exists", or "no existing reservation overlaps the dates you requested", or "your account balance still has enough to cover that purchase." Only the database can reliably validate data which depends on related data. Developers regularly screw this up, but PostgreSQL provides some good solutions.