前言
最近在搞个安全需求,需要对敏感字段做加密存储。于是,,于是我就躺了个坑。
方案梳理
方案一:基于Mybatis的拦截器Interceptor
我的第一个反应其实是基于Mybatis的拦截器Interceptor机制实现,在设置参数的时候对参数进行拦截并加密,而在查询的时候对返回值进行解密。当然,不管是那种方案都需要对敏感字段进行标记。
实现可参考mybatis-plus实现数据字段加解密
PS: 该博客可以满足绝大部分场景了,但Map、List<String>没有考虑。不过这也是基于Interceptor的弊端,就是你需要考虑更多的细节。
方案二:基于Mybatis的TypeHandler
Mybatis支持针对特定字段的类型进行特殊处理,这为字段的加解密提供了可能。关于Mybatis的TypeHandler,大家可以看看官方的【类型处理器(typeHandlers)】
简单来说就一句话:在执行SQL之前对入参和返回值进行处理。
而Mybatis本身通过这个进行类型转换。想知道其自带了多少TypeHandler可以看看mybatis的这个包:org.apache.ibatis.type
基于这个特点,我们就可以利用来实现字段的加解密功能。为了不影响那些不需要加解密的字段,我们就必须要在在特定的字段上进行指定。
对于select,可以通<resultMap>标签来指定,例如:
<resultMap type="org.apache.ibatis.submitted.rounding.User" id="usermap2">
<result column="roundingMode" property="roundingMode" typeHandler="org.apache.ibatis.type.EnumTypeHandler"/>
</resultMap>
对于入参,则不需要区分是什么语句,只需要在取值的时候指定就行:
<insert id="insert2">
insert into users2 (id, name, funkyNumber, roundingMode)
values(#{id}, #{name}, #{funkyNumber},
#{roundingMode, typeHandler= org.apache.ibatis.type.EnumTypeHandler})
</insert>
这便是我们基于Mybatis实现加解密的理论基础。
MybatisPlus优雅实现加解密
众所周知,MybatisPlus并不准备取代Mybatis,而是对Mybatis的增强,增加一些便于使用的特性。
以TypeHandler为例:
@TableName(value = "foo_user", autoResultMap = true)
public class User {
private String username;
@TableField(typeHandler = MyTypeHandler.class)
private String mobile;
}
public interface UserMapper extends BaseMapper<User> {
}
就这样,我们就完成了MybatisPlus(官方源码缩写为mp)的配置。我们可以很方便的调用UserMapper#insert方法,通过上面指定的typeHandler来执行我们需要对mobile字段的加密逻辑。
调用UserMapper#selectById方法,也会自动的执行typeHandler的解密逻辑。后者,通过@TableName的autoResultMap = true
配置生效,他会自动向Mybatis中注入一个ResultMap,其效果等同于我们在xml文件中书写的resultMap。
感兴趣的同学,可以参考这篇文章:
基于MybatisPlus的实现
MybatisPlus真的这么优雅丝滑?
事情并没有这么简单!前面我们大致了解了Mybatis本身提供的TypeHandler组件,也知道MybatisPlus的基于TypeHandler为我们提供的简单易用的优雅的使用方式。可是,各位同学想过没有,我们自己在xml中写的SQL呢?MybatisPlus也能如此智能、方便地达到我们的目的呢???
很显然,不能够。我们在xml中写update语句,没有指定typeHandler的话,是MybatisPlus也是无能为力的。这是因为他不能掌握我们的SQL了,更不能为我们添加指定typeHandler。这对于select语句也是如此!
事实上,MybatisPlus在其注解之上也有说明:
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.ANNOTATION_TYPE})
public @interface TableField {
JdbcType jdbcType() default JdbcType.UNDEFINED;
Class<? extends TypeHandler> typeHandler() default UnknownTypeHandler.class;
}
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.ANNOTATION_TYPE})
public @interface TableName {
boolean autoResultMap() default false;
}
清楚明白地写着只支持自动生成的方法。
要命的是,我们在实际项目中,不可能只使用单表查询,这样一来,我们就不得不自己写SQL。然而,当你使用MybatisPlus这么方便愉快地写代码的时候,你还会深入源码看注释吗?还会深入源码了解其实现原理吗?不,你不会,本来就是因为懒才使用MybatisPlus的。这就使得很多同学陷入迷茫,排查问题不知所措:为什么就是不生效,为什么这个方法可以?想想都崩溃!
总结
- MybatisPlus的@TableField注解的部分字段只使用于自动生成的方法,因为它可以掌控和改造目标SQL的生成。本质上还是在使用Mybatis的功能。例如:指定typeHandler、javaType。
- Mybatis本身提供了TypeHandler组件,我们可以基于这个来实现敏感字段的加解密。
后记
给大家个建议,如果你想偷懒,而且你的项目足够简单,简单到通过单表操作就能够解决问题,那么可以使用MybatisPlus。否则,我不建议大家使用MybatisPlus,尤其不建议使用这种半吊子的功能。实际上,MybatisPlus主要还是希望基于Mybatis给大家提供一些好用的特性。但是,随着我使用地越多,就越不想使用它。上一个躺坑的是,我需要通过mockito来mock这些Mapper,来做单元测试。简直麻了,因为它自动生成的方法太灵活了,尤其是链式方法。