首页 > 数据库 >Security整合Redis为何序列化报错_配专用反序列化器

Security整合Redis为何序列化报错_配专用反序列化器

来源：互联网 2026-04-26 21:15:08

Security对象反序列化必报错，因Spring Security内置类无无参构造器且Jackson默认不识别；需配置ObjectMapper开启DefaultTyping、可见性，并注册SimpleGrantedAuthorityDeserializer和UsernamePasswordAuth

Security对象反序列化必报错，因Spring Security内置类无无参构造器且Jackson默认不识别；需配置ObjectMapper开启DefaultTyping、可见性，并注册SimpleGrantedAuthorityDeserializer和UsernamePasswordAuthenticationToken MixIn。

把Security对象存进Redis后取不出来，这事儿太常见了。问题往往不是配置漏了，而是反序列化器没对上类型——尤其是像 SimpleGrantedAuthority、UsernamePasswordAuthenticationToken 这类Spring Security框架的内置类，Jackson默认根本不认识它们。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

为什么 Security 对象反序列化必报错

Spring Security的认证对象（比如 Authentication、SecurityContext）在设计上就和标准POJO不太一样。它们大多没有无参构造器，身上也没贴 @JsonCreator 注解。Jackson默认只认规规矩矩的POJO，一碰到这些“特立独行”的类，处理方式就很简单粗暴：直接退化成 LinkedHashMap。结果呢？最后抛出那个经典的 ClassCastException: LinkedHashMap cannot be cast to SecurityContext。更棘手的是 SimpleGrantedAuthority，它的构造参数虽然只是个 String，但在JSON序列化后，可能变成一个带了 @class 字段的复杂结构，反序列化时自然找不到匹配的构造器。

必须配 `ObjectMapper` + `DefaultTyping`

光用一个 Jackson2JsonRedisSerializer 是远远不够的，关键得让它“认识”并记住这些对象的运行时类型信息。这就必须对底层的 ObjectMapper 进行精准配置：

objectMapper.enableDefaultTyping(ObjectMapper.DefaultTyping.NON_FINAL) —— 这是核心，让所有非final类在序列化时自动带上 @class 字段，记录类型。
objectMapper.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY) —— 放宽可见性规则，允许Jackson访问私有字段和getter方法。
最后，也是最容易漏掉的一步：必须调用 jsonSerializer.setObjectMapper(objectMapper)，否则上面的配置全是白费功夫。

这三条，漏掉任意一条，反序列化都会在类型还原的关键阶段失败。

自定义 `SimpleGrantedAuthorityDeserializer` 是刚需

即便开了 DefaultTyping，SimpleGrantedAuthority 这个类因为其特殊的构造方式，仍然可能反序列化失败。这时候，一个专用的反序列化器就成了必需品：

public class SimpleGrantedAuthorityDeserializer extends StdDeserializer {
    public SimpleGrantedAuthorityDeserializer() {
        super(SimpleGrantedAuthority.class);
    }

    @Override
    public SimpleGrantedAuthority deserialize(JsonParser p, DeserializationContext ctxt)
            throws IOException {
        JsonNode node = p.getCodec().readTree(p);
        String authority = node.has("authority")  node.get("authority").asText() : node.asText();
        return new SimpleGrantedAuthority(authority);
    }
}

写好之后，别忘了把它注册到 ObjectMapper 里：

SimpleModule module = new SimpleModule();
module.addDeserializer(SimpleGrantedAuthority.class, new SimpleGrantedAuthorityDeserializer());
objectMapper.registerModule(module);

别忽略 `UsernamePasswordAuthenticationToken` 的构造约束

这个类的情况又有所不同。它只有带参构造器，并且参数顺序是固定的（principal, credentials, authorities）。Jackson需要明确知道如何传递这些参数，否则就会报 Cannot construct instance... no Creators 的错误。通常有两种应对策略：

第一种，给你自己的子类加上 @JsonCreator 和 @JsonProperty 注解。但这种方式不推荐，因为修改框架类或其子类会带来侵入性。
第二种，也是更优雅安全的方式：使用MixIn。具体操作是，新建一个空的 UsernamePasswordAuthenticationTokenMixin 类，在里面通过 @JsonCreator(mode = JsonCreator.Mode.PROPERTIES) 和对应的 @JsonProperty 注解来定义反序列化规则。然后通过 objectMapper.addMixIn(UsernamePasswordAuthenticationToken.class, UsernamePasswordAuthenticationTokenMixin.class) 进行绑定。这种方式无侵入，也避免了直接开启 AutoTypeSupport(true) 可能带来的反序列化安全风险。

话说回来，真正让人卡住的地方，往往不是“知不知道要配”，而是配置了却没生效。比如，ObjectMapper 实例没真正挂载到序列化器上，或者MixIn的注册顺序错了——如果在 setObjectMapper 之后才注册模块，那这个模块压根就不会起作用。这些细节，才是解决问题的关键所在。

侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述