Spring Security Reactive登出处理器执行顺序要求及异常原因排查

问题场景 #

使用Spring Security Reactive结合Spring Session Redis时，参考官方文档的登出处理器示例：

new DelegatingServerLogoutHandler(
    new WebSessionServerLogoutHandler(), new SecurityContextServerLogoutHandler()
);

实际运行中发现，若先执行WebSessionServerLogoutHandler会出现会话失效问题，调换顺序先执行SecurityContextServerLogoutHandler则正常。疑问点：

1. 登出处理器的执行是否有强制顺序要求？
2. 该问题是Spring Security还是Spring Session的问题？

解答 #

1. 登出处理器的执行顺序要求 #

DelegatingServerLogoutHandler会严格按照构造方法传入的顺序依次执行处理器，官方文档给出的顺序并非强制标准，它只是针对默认WebSession（未集成Spring Session Redis）场景的推荐写法。实际顺序需要根据你使用的会话管理组件和业务逻辑调整。

2. 顺序导致会话失效的原因 #

这个问题是Spring Session Redis与Spring Security协同工作时的逻辑适配问题，而非两者的BUG：

• 当先执行WebSessionServerLogoutHandler时，它会立即标记当前WebSession为失效，Spring Session Redis会同步删除Redis中存储的会话数据。此时后续的SecurityContextServerLogoutHandler需要访问与该会话绑定的SecurityContext，但会话已被销毁，就会触发会话失效的异常。
• 调换顺序后，SecurityContextServerLogoutHandler先清除SecurityContext（此时会话仍存在，可正常获取上下文），之后WebSessionServerLogoutHandler再失效会话，整个流程逻辑通顺，不会出现异常。

总结 #

• 登出处理器没有全局强制的执行顺序，需结合会话管理组件调整；
• 集成Spring Session Redis时，推荐先执行SecurityContextServerLogoutHandler，再执行WebSessionServerLogoutHandler，避免会话提前销毁导致的上下文操作异常。

内容的提问来源于stack exchange，提问作者quentinLi