应用场景
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反序列化时修改类的全限定性名解析的全部内容，希望对大家有所帮助。感兴趣的朋友可以继续参阅本站其它相关专题，如有不足之处，欢迎留言指出。感谢朋友们对本站的支持！
如对本文有疑问， 点击进行留言回复！！
![[杭电多校2020]第一场 1004 Distinct Sub-palindromes](http://www.lhsxpumps.com/_images5/10qianwan/20200724/s_0_202007241733388592.png)
[杭电多校2020]第一场 1004 Distinct Sub-palindromes
Swift -- 将本地生成的UIImage进行持久化保存（存到文件中fileManager.createFile）
网友评论