刚才在实现了注册功能的时候,发现了一个问题: 由于服务器端没有进行数据校验, 容易被绕过前端直接发送请求.
因此使用Hibernate-Validator框架完成数据校验:
依赖
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator</artifactId>
<version>5.2.1.Final</version>
</dependency>
Hibernate-Validator 相关概念:
- hibernate Validator 是 Bean Validation 的参考实现 。
- Hibernate Validator 提供了 JSR 303 规范中所有内置 constraint(约束) 的实现,除此之外还有一些附加的 constraint。
- 在日常开发中,Hibernate Validator经常用来验证bean的字段,基于注解,方便快捷高效。
常用注解如下:
constraint | detail |
---|---|
@valid | 被注释对象是一个对象, 检查该对象所有子弹 |
@Null | 被注释字段必须为空 |
@NotNull | 被注释字段必须不为空 |
@AsserTrue | 被注释字段为true |
@AsserFalse | 被注释字段为false |
@Min(value) | 被注释字段为number,大于等于value |
@Max(value) | 被注释字段为number,小于等于value |
@DecimalMin(value) | 被注释的元素必须是一个数字,其值必须大于等于指定的最小值 |
@DecimalMax(value) | 被注释的元素必须是一个数字,其值必须小于等于指定的最大值 |
@Size(max, min) | 被注释的元素的大小必须在指定的范围内 |
@Pattern(value) | 被注释的元素必须符合指定的正则表达式 |
@Length | 被注释的字符串的大小必须在指定的范围内 |
@NotEmpty | 被注释的字符串的必须非空 |
@CreditCardNumber | 被注释的字符串必须通过Luhn校验算法,银行卡,信用卡等号码一般都用Luhn计算合法性 |
demo
@Table(name = "tb_user")
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;
@Length(min = 4, max = 30, message = "用户名长度必须在4-30位之间")
private String username;// 用户名
@JsonIgnore // 在json序列化为对象时,不会把该字段返回
@Length(min = 4, max = 30, message = "用户名长度必须在4-30位之间")
private String password;// 密码
@Email
private String email;// 电话
}