JDK反序列化时修改类的全限定性名解析
应用场景
SpringSecurityOAuth2有一个奇葩的设计,那就是它将与access_token相关的所有属于都封装到OAuth2AccessToken中,然后保存时会直接将该对象序列化成字节写入数据库。我们在资源服务器中想要直接读数据库来取出access_token来验证令牌的有效性,然而又不想引入SpringSecurity的相关依赖污染jar包。这时可以将SpringSecurity中OAuth2AccessToken的唯一实现类DefaultOAuth2AccessToken的源码copy到我们的项目中,然后通过JDBC读取byte[],通过JDK自带的反序列化机制来还原DefaultOAuth2AccessToken对象。这时就会遇到问题,即原来的OAuth2AccessToken所在包是以org.springframework.security开头的,而我们copy过来源码后,包名是以我们自己定义的包cn.com.XXXX开头的,这样在反序列化时,即使两个类的字段完全一样,但由于字节流中存储的类信息的全限定性名不同,也会导致反序列化失败。
解决方案
我们可以定义子类继承JDK的ObjectInputStream,然后重写readClassDescriptor()方法:
@Override protected ObjectStreamClass readClassDescriptor() throws IOException, ClassNotFoundException { ObjectStreamClass read = super.readClassDescriptor(); if (read.getName().startsWith("原包名")) { Class type = Class.forName(read.getName().replace("新包名")); return ObjectStreamClass.lookup(type); } return read; }
这样在反序列化时就不会报错了。原理并不复杂,其实就是在解析字节流时,将解析后应为org.springframework.security.oauth2.common.DefautOAuthToken的class,替换成了我们自己copy过来源码的cn.com.XXXXXX.DefaultOAuthToken从而达到”欺骗”的目的。在该场景下,我们就可以做到在资源提供方不引入SpringSecurity框架而只使用SpringSecurityOAuth2的授权服务。资源提供方直接读数据库来验证令牌的有效性,而不是向授权服务查询。
总结
以上就是本文关于JDK反序列化时修改类的全限定性名解析的全部内容,希望对大家有所帮助。感兴趣的朋友可以继续参阅本站其它相关专题,如有不足之处,欢迎留言指出。感谢朋友们对本站的支持!
您可能感兴趣的文章:
- JDK反序列化时修改类的全限定性名
- 修改IntelliJ IDEA中Maven项目的默认JDK版本
- Bos平台修改发布业务单元的jdk版本
- 在mac操作系统下,Intellij IDEA默认jdk版本的修改
- 修改protostuff-runtime源码排序实体类字段,解决安卓和java服务器序列化不一致
- 修改dbvisualizer的jdk版本
- Java拾遗:004 - JDK、Hadoop、Hessian序列化
- 在同一台机器上安装多个版本jdk,修改环境变量不生效
- 在同一台机器上安装多个版本jdk,修改环境变量不生效
- 修改linux默认jdk版本
- spring-data-redis 整合,以及使用kryo序列化代替jdk原生序列化机制
- 修改Weblogic的JDK路径以解决其不能正常启动的问题
- MyEclipse中JDK的修改
- CentOS 6.5修改JDK环境
- JAVA项目JDK版本修改
- Maven Junit修改JDK编译版本
- 关于JAVA_HOME路径修改之后,JDK的版本依然不更改的问题
- spark优化:spark.serializer修改序列化方式
- 得瑟一下jdk源代码解析,如何在运行时修改java final变量
- Maven 修改eclipse默认jdk版本