验证服务器控件是否比 javascript 更好?它们是否限制了我们,因为我们只能使用它们提供的功能。请帮助我。我在自己的博客上阅读了有关验证服务器控件的信息
4 回答
最好在客户端和服务器上都使用验证:
- 在客户端上进行验证可以提供即时反馈,而无需经常往返于服务器。这有助于更好的用户体验。
- 需要在服务器上进行验证以确保您不会收到错误数据。毕竟,恶意用户可以轻松地将数据发布到您的服务器,而无需经过您的客户端验证。
现在,至于您如何实现该验证 - 如果内置的“工具包”控件为您执行适当的验证,那显然比编写自己的验证代码更简单。ASP.NET 验证器为您执行客户端和服务器端验证。从文档中BaseValidator
:
验证控件始终验证服务器上关联的输入控件。验证控件还具有完整的客户端实现,允许启用脚本的浏览器(例如 Microsoft Internet Explorer 4.0 版和更高版本)在客户端上执行验证。客户端验证通过在将用户输入发送到服务器之前检查用户输入来增强验证过程。这允许在提交表单之前在客户端检测到错误,从而避免服务器端验证所需的信息往返。
通常,您始终应该进行服务器端数据验证。这可以确保您保护您的服务器免受恶意伪造的请求,您的数据存储不会输入无效数据(只要数据库本身不处理)。如果您喜欢使用工具或框架进行服务器端输入验证,如您链接的文章中所述,这取决于您。
客户端验证(例如 javascript)也很有用,但出于不同的原因:它允许您在提交数据之前向用户提供有用的信息。
所以这不是非此即彼的问题,更多的是和/和。你实际上并没有在这里做任何双重工作。客户端和服务器端验证只是用于不同的目的(分别增强用户的可用性和保护服务的逻辑和安全性)。
服务器端和客户端验证可能由相同的业务逻辑管理(例如,对于邮政编码,您可以使用相同的正则表达式来检查和拒绝服务器端和客户端的输入)。在这种情况下,您将面临同步两个验证层的挑战(可以通过从与服务器端服务代码相同的业务逻辑模型生成页面 + javascript 逻辑来完成)。
如果你仍然觉得你在做双重工作,那么选择做服务器端验证。(当然,您仍然可以使用它来通知客户端,但这样做需要响应。)客户端验证不提供任何保护,因为客户端可以简单地手动伪造请求,或者从浏览器禁用javascript,或修改客户端javascript trhough 之类的greasemonkey 脚本。
用户可以关闭 JavaScript,在这种情况下,您的验证例程将无法工作。最好在前端和服务器都进行验证。
我从未在 ASP 上工作过,但据我猜测 ValidationServerControls 是开箱即用的控件,可为您提供服务器端验证和客户端验证。(我可能错了)。但据我了解,组件的服务器端验证始终是必需的;因为在 javascript 中进行验证是远远不够的。客户端始终可以禁用 javascript 并提交内容或使用复杂的工具(如 curl 等)将请求发布到可能包含数据的服务器;这可能会在您的代码/sql 中进行注入。
即使您编写 javascript 验证;您必须以一种或另一种方式始终编写服务器代码来验证传入数据。
理想的方法是两者兼有 1. 在 javascript 中验证数据;以便在无效数据输入的情况下限制对服务器的请求。2. 服务器端验证。如果 javascript 被禁用并且数据发布到服务器。