ASP.NET 表单验证方法与客户端(浏览器)服务器交互机制的故事

想到这个问题完全是一个意外吧,是在寻找另外一个问题答案的过程中,才对验证方法浏览器服务器交互机制的关系有了清晰的认识。

先说下验证方法,验证方法分为前台验证后台验证

前台验证就是类似jQuery.Validate这类的插件,当然也可以我们自己写。

后台验证就是ASP.NET自带的验证控件,如RequiredFieldValidator。

记得初学.NET的时候,那会儿接触验证控件,也知道验证分为前台,后台。但是随着时间的推移,由于做的项目基本上都是公司内部使用的软件,比如OA。因为这种项目对安全性要求没有那么高。所以追随着老员工直接就用前台验证去做每个项目,代替的是慢慢的忘记了两者是有不同的这个事实。直到昨天,才好像唤起了以前的记忆,恍然大悟的感觉。

对于验证,如果我们同时加前台验证和后台验证,这样会使项目的安全性提高,但相对的来说,会消耗一些性能。选择哪样就要看你更需要哪样。

再说下客户端(浏览器)服务器交互机制

有点大白话:浏览器会封装一个请求报文(可以理解为信),发给服务器,服务器解析这个报文,进行重组,生成一个响应报文,回发给浏览器

(回信),浏览器收到后再对其进行解析,就生成了我们看到的网页和一些我们看不到的数据。它们之间的通信都是遵循HTTP协议。

那两者会有怎样的“故事”呢?

是这样的,如果我只使用前台验证,也就是在我点击提交按钮之后,浏览器封装请求报文之前去验证,如果发现有不合格的地方,就直接提示错误,也就不会有之后的请求报文,也就不会与服务器有交互的动作,所有动作都是在客户端本地去做的。

如果只使用后台验证,那么无论表单上的内容合格不合格,这个请求报文是指定发出去了,服务器收到后去做验证,之后把验证结果返给浏览器。

所以说前台验证安全性差,后台验证安全性强,但是会增加服务器端的负荷。

通常如果项目是内部使用的,如OA之类的,其实完全可以只使用前台验证,这就明白了为什么单位的老员工都只写前台验证方法了。

如果项目是对外使用的话,那么就用后台验证就可以了,不过加上前台验证的话,会更好一些,因为加了前台验证,会大大减轻服务器的负荷,比如验证个非空,就可以直接在前台干掉,不用访问服务器。如果验证与数据相关,那样才有必要访问服务器。

 

这就是它和它的故事,比较基础的知识点,作为一个记录,高手勿喷~

ASP.NET 表单验证方法与客户端(浏览器)服务器交互机制的故事,古老的榕树,5-wow.com

郑重声明:本站内容如果来自互联网及其他传播媒体,其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享,并不代表本站赞同其观点和对其真实性负责,也不构成任何其他建议。