后台参数验证的几种方式
前台和后台验证(MVC、Struts2)的必要性经验总结:
1.后端验证是必需的,只有后端验证才能保证表单数据输入的合法性,前端验证的主要目的是为了方便用户,增强用户体验。
2.虽然不是必需的,但目前也算是一种发展趋势,特别是面向一般用户的网站,没有加前端验证可能会加大用户注册跑路率。
3.前端验证方式:
1)目前主流的Web框架已经集成了前后端验证功能,如:Asp.net mvc,PHP 的Yii 等,只要定好验证规则,前端验证代码就自动生成好,后端验证也很方便。
2)前端验证代码除非特殊情况或以学习练习为目的,就不要再自己一个个写了,因为实际开发的时候是根本没时间让你慢慢自个去写的。
3)真正工作时使用一般使用: jquery.validate.js 插件才能体会到前端验证的酸爽,通过插件可以使用一些自带的验证方式,也可以自定义验证规则
4.如果还不会使用jquery.validate.js可以去看我博客的另一篇文章《jquery.validate.js的使用教程》,一定会让你受益匪浅的
---------------------
后端校验比前端校验更安全,更可靠,前端校验可以增加用户体验,一般来说,在前端校验的东西在后端也必须校验(比如登陆用户名、密码),有些东西在前端就可以校验,比如:字符串长度、邮箱格式、手机号码等等,没必要提交到后端,增加服务器的压力,正常情况下,前端校验的东西,最好后端都在校验一次。
放到后端校验的,常见的与数据库有关,比如输入重复之类的,需要先查询数据库才知道,当然还有其他的一些东西。
//java检测是否为电话号码(手机、固定电话验证)
String legalPhone = "";
String regExp ="^((13[0-9])|(15[^4,\\D])|(18[0,5-9]))\\d{8}|[0]{1}[0-9]{2,3}-[0-9]{7,8}$";
Pattern p = Pattern.compile(regExp);
Matcher m = p.matcher(importPotentialBFOs[i].getLegalPhone());
if(m.find()){ //注意:m.find只能用一次,第二次调用后都为false
legalPhone = importPotentialBFOs[i].getLegalPhone();
uploadTmp.setLegalTelephone(legalPhone);
}else{
throw new BizException("联系电话格式错误!");
}
---------------------
参数验证是一个常见的问题,无论是前端还是后台,都需对用户输入进行验证,以此来保证系统数据的正确性。对于web来说,有些人可能理所当然的想在前端验证就行了,但这样是非常错误的做法,前端代码对于用户来说是透明的,稍微有点技术的人就可以绕过这个验证,直接提交数据到后台。无论是前端网页提交的接口,还是提供给外部的接口,参数验证随处可见,也是必不可少的。总之,一切用户的输入都是不可信的。
参数验证有许多种方式进行,下面以mvc为例,列举几种常见的验证方式,假设有一个用户注册方法
[HttpPost]
public ActionResult Register(RegisterInfo info)
一、通过 if-if 判断
1
2
3
4
5
6
7
8
|
if ( string .IsNullOrEmpty(info.UserName)) { return FailJson( "用户名不能为空" ); } if ( string .IsNullOrEmpty(info.Password)) { return FailJson( "用户密码不能为空" ) } |
逐个对参数进行验证,这种方式最粗暴,但当时在WebForm下也确实这么用过。对于参数少的方法还好,如果参数一多,就要写n多的if-if,相当繁琐,更重要的是这部分判断没法重用,另一个方法又是这样判断。
二、通过 DataAnnotation
mvc提供了DataAnnotation对Action的Model进行验证,说到底DataAnnotation就是一系列继承了ValidationAttribute的特性,例如RangeAttribute,RequiredAttribute等等。ValidationAttribute 的虚方法IsValid 就是用来判断被标记的对象是否符合当前规则。asp.net mvc在进行model binding的时候,会通过反射,获取标记的ValidationAttribute,然后调用 IsValid 来判断当前参数是否符合规则,如果验证不通过,还会收集错误信息,这也是为什么我们可以在Action里通过ModelState.IsValid判断Model验证是否通过,通过ModelState来获取验证失败信息的原因。例如上面的例子:
1
2
3
4
5
6
7
8
|
public class RegisterInfo { [Required(ErrorMessage= "用户名不能为空" )] public string UserName{ get ; set ;} [Required(ErrorMessage= "密码不能为空" )] public string Password { get ; set ; } } |
事实上在webform上也可以参照mvc的实现原理实现这个过程。这种方式的优点的实现起来非常优雅,而且灵活,如果有多个Action共用一个Model参数的话,只要在一个地方写就够了,关键是它让我们的代码看起来非常简洁。
不过这种方式也有缺点,通常我们的项目可能会有很多的接口,比如几十个接口,有些接口只有两三个参数,为每个接口定义一个类包装参数有点奢侈,而且实际上为这个类命名也是非常头疼的一件事。
三、DataAnnotation 也可以标记在参数上
通过验证特性的AttributeUsage可以看到,它不只可以标记在属性和字段上,也可以标记在参数上。也就是说,我们也可以这样写:
1
|
public ActionResult Register([Required(ErrorMessage= "用户名不能为空" )] string userName, [Required(ErrorMessage= "密码不能为空" )] string password) |
这样写也是ok的,不过很明显,这样写很方法参数会难看,特别是在有多个参数,或者参数有多种验证规则的时候。
四、自定义ValidateAttribute
我们知道可以利用过滤器在mvc的Action执行前做一些处理,例如身份验证,授权处理的。同理,这里也可以用来对参数进行验证。FilterAttribute是一个常见的过滤器,它允许我们在Action执行前后做一些操作,这里我们要做的就是在Action前验证参数,如果验证不通过,就不再执行下去了。
定义一个BaseValidateAttribute基类如下:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
public class BaseValidateAttribute : FilterAttribute { protected virtual void HandleError(ActionExecutingContext context) { for ( int i = ValidateHandlerProviders.Handlers.Count; i > 0; i--) { ValidateHandlerProviders.Handlers[i - 1].Handle(context); if (context.Result != null ) { break ; } } } } |
HandleError 用于在验证失败时处理结果,这里ValidateHandlerProviders提过IValidateHandler用于处理结果,它可以在外部进行注册。IValidateHandler定义如下:
1
2
3
4
|
public interface IValidateHandler { void Handle(ActionExecutingContext context); } |
ValidateHandlerProviders定义如下,它有一个默认的处理器。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
public class ValidateHandlerProviders { public static List<IValidateHandler> Handlers { get ; private set ; } static ValidateHandlerProviders() { Handlers = new List<IValidateHandler>() { new DefaultValidateHandler() }; } public static void Register(IValidateHandler handler) { Handlers.Add(handler); } } |
这样做的目的是,由于我们可能有很多具体的ValidateAttribute,可以把这模块独立开来,而把最终的处理过程交给外部决定,例如我们在项目中可以定义一个处理器:
1
2
3
4
5
6
7
8
9
10
|
public class StanderValidateHandler : IValidateHandler { public void Handle(ActionExecutingContext filterContext) { filterContext.Result = new StanderJsonResult() { Result = FastStatnderResult.Fail( "参数验证失败" , 555) }; } } |
然后再应用程序启动时注册:ValidateHandlerProviders.Handlers.Add(new StanderValidateHandler());
ValidateNullttribute:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
|
public class ValidateNullAttribute : BaseValidateAttribute, IActionFilter { public bool ValidateEmpty { get ; set ; } public string Parameter { get ; set ; } public ValidateNullAttribute( string parameter, bool validateEmpty = false ) { ValidateEmpty = validateEmpty; Parameter = parameter; } public void OnActionExecuting(ActionExecutingContext filterContext) { string [] validates = Parameter.Split( ',' ); foreach ( var p in validates) { string value = filterContext.HttpContext.Request[p]; if (ValidateEmpty) { if ( string .IsNullOrEmpty(value)) { base .HandleError(filterContext); } } else { if (value == null ) { base .HandleError(filterContext); } } } } public void OnActionExecuted(ActionExecutedContext filterContext) { } } |
ValidateRegexAttribute:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
|
public class ValidateRegexAttribute : BaseValidateAttribute, IActionFilter { private Regex _regex; public string Pattern { get ; set ; } public string Parameter { get ; set ; } public ValidateRegexAttribute( string parameter, string pattern) { _regex = new Regex(pattern); Parameter = parameter; } public void OnActionExecuting(ActionExecutingContext filterContext) { string [] validates = Parameter.Split( ',' ); foreach ( var p in validates) { string value = filterContext.HttpContext.Request[p]; if (!_regex.IsMatch(value)) { base .HandleError(filterContext); } } } public void OnActionExecuted(ActionExecutedContext filterContext) { } } |
更多的验证同理实现即可。
这样,我们上面的写法就变成:
1
2
|
[ValidateNull( "userName,password" )] public ActionResult Register( string userName, string password) |
综合看起来,还是ok的,与上面的DataAnnotation可以权衡选择使用,这里我们可以扩展更多有用的信息,如错误描述等等。
总结
当然每种方式都有有缺点,这个是视具体情况选择了。一般参数太多建议就用一个对象包装了。