JDK反序列化时修改类全限定性名的示例分析

发布时间:2021-07-23 09:17:55 作者:小新
来源:亿速云 阅读:122

小编给大家分享一下JDK反序列化时修改类全限定性名的示例分析,希望大家阅读完这篇文章之后都有所收获,下面让我们一起去探讨吧!

应用场景

SpringSecurityOAuth3有一个奇葩的设计,那就是它将与access_token相关的所有属于都封装到OAuth3AccessToken中,然后保存时会直接将该对象序列化成字节写入数据库。我们在资源服务器中想要直接读数据库来取出access_token来验证令牌的有效性,然而又不想引入SpringSecurity的相关依赖污染jar包。这时可以将SpringSecurity中OAuth3AccessToken的唯一实现类DefaultOAuth3AccessToken的源码copy到我们的项目中,然后通过JDBC读取byte[],通过JDK自带的反序列化机制来还原DefaultOAuth3AccessToken对象。这时就会遇到问题,即原来的OAuth3AccessToken所在包是以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.oauth3.common.DefautOAuthToken的class,替换成了我们自己copy过来源码的cn.com.XXXXXX.DefaultOAuthToken从而达到”欺骗”的目的。在该场景下,我们就可以做到在资源提供方不引入SpringSecurity框架而只使用SpringSecurityOAuth3的授权服务。资源提供方直接读数据库来验证令牌的有效性,而不是向授权服务查询。

看完了这篇文章,相信你对“JDK反序列化时修改类全限定性名的示例分析”有了一定的了解,如果想了解更多相关知识,欢迎关注亿速云行业资讯频道,感谢各位的阅读!

推荐阅读:
  1. jdk--配置tomcat时的jdk
  2. js下载文件并修改文件名的示例分析

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

jdk

上一篇:ThinkPHP5.1框架页面跳转及修改跳转页面模版的示例分析

下一篇:如何修改Laravel自带认证系统的User类命名空间

相关阅读

您好,登录后才能下订单哦!

密码登录
登录注册
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》