应用场景

Spring Security OAuth2有一个奇葩的设计，那就是它将与access_token相关的所有属于都封装到OAuth2AccessToken中，然后保存时会直接将该对象序列化成字节写入数据库。我们在资源服务器中想要直接读数据库来取出access_token来验证令牌的有效性，然而又不想引入Spring Security的相关依赖污染jar包。这时可以将Spring Security中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从而达到”欺骗”的目的。在该场景下，我们就可以做到在资源提供方不引入 Spring Security 框架而只使用Spring Security OAuth2的授权服务。资源提供方直接读数据库来验证令牌的有效性，而不是向授权服务查询。

最后

以上就是文艺丝袜为你收集整理的JDK反序列化时修改类的全限定性名应用场景解决方案的全部内容，希望文章能够帮你解决JDK反序列化时修改类的全限定性名应用场景解决方案所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。