过期登录令牌刷新问题（LifecycleAwareSessionManager）

这个问题我之前在处理Vault客户端集成时也碰到过——LifecycleAwareSessionManager的默认续期逻辑确实只覆盖了令牌为空或者服务器返回合法4XX的场景，像连接超时这类IO异常根本不会触发重新登录，结果就是客户端抱着过期令牌反复请求，自然全是403。下面是几个可行的解决思路：

1. 扩展LifecycleAwareSessionManager，捕获连接超时异常触发重登 #

最直接的方式是自定义SessionManager，继承LifecycleAwareSessionManager并重写renewSession方法，把连接超时这类IO异常纳入触发重新登录的条件：

public class CustomLifecycleSessionManager extends LifecycleAwareSessionManager {

    // 复用父类构造逻辑
    public CustomLifecycleSessionManager(ClientAuthentication clientAuthentication, WebClient webClient, SessionManagerSupport sessionManagerSupport) {
        super(clientAuthentication, webClient, sessionManagerSupport);
    }

    @Override
    protected Mono<Void> renewSession(Session session) {
        return super.renewSession(session)
                .onErrorResume(throwable -> {
                    // 捕获连接超时或更宽泛的IO异常
                    if (throwable instanceof ConnectTimeoutException || throwable instanceof IOException) {
                        // 标记当前会话无效，触发重新登录流程
                        return login()
                                .then(Mono.empty());
                    }
                    // 其他异常按原逻辑抛出
                    return Mono.error(throwable);
                });
    }
}

这样只要续期时碰到连接超时，就会立刻调用login()获取新令牌，替换掉过期的旧令牌。

2. 增加全局请求拦截/重试机制，处理403后的令牌刷新 #

如果不想修改SessionManager的核心逻辑，可以在Vault客户端的请求链里加一层拦截器：

• 每次调用Vault前，先检查当前令牌的续期状态（比如记录上次续期是否因超时失败）
• 当收到403响应时，结合之前的续期异常记录判断是否是令牌过期导致的，触发重新登录后再重试当前请求

这里要注意加并发控制，比如用AtomicBoolean标记是否正在登录，避免多个线程同时触发登录请求造成资源浪费。

3. 前置令牌有效性校验，避免用过期令牌请求 #

在每次调用Vault接口前，主动校验令牌的有效性：

• 调用Vault的auth/token/lookup-self接口，检查当前令牌是否有效
• 如果校验时碰到连接超时或者返回403，直接触发重新登录，获取新令牌后再执行原请求

这种方式虽然会多一次请求，但能从根源上避免用过期令牌发起调用，适合对数据一致性要求较高的场景。

最后提醒一句：不管用哪种方案，都要做好重试次数的限制，避免因为网络波动导致无限循环登录哦。

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