【问题标题】:pre-emptive refresh of expired JWT token过期 JWT 令牌的抢先刷新
【发布时间】:2018-07-22 18:30:47
【问题描述】:

我在搜索时发现的所有解决方案都会在触发逻辑以刷新过期令牌之前响应来自 API 调用的 401 响应。就我而言,我使用 react-cognito 将 redux 存储中的到期时间置于 cognito.user.signInUserSession.idToken.payload.exp 下(整数代表 unix 时间)。

我想尝试实施一个方案,其中过期被抢占,如果可行,我想将此逻辑与我的 API 调用代码分开。

我探索的一个选项是为 currentTime - expiryTime - someBuffer 设置超时,但这可能长达 50 分钟或更长时间,而且我读过长时间运行的超时通常是不可靠的,具有奇怪的性能,尤其是当浏览器选项卡不是时焦点。

我考虑的另一个选项是循环运行的 saga,由 LOGGED_IN 操作启动并由 LOGGED_OUT 操作结束,它检查几乎过期的令牌并刷新它。在移动设备上,我的理解是代码执行在浏览器处于后台时暂停 - 因此这种方法将有一个极端情况,如果用户在令牌到期后将浏览器置于前台,那么时间窗口等于循环间隔其中 API 调用将 401。循环间隔可以做得更小,但永远无法消除边缘条件。

是否有某种方案可以在令牌到期之前可靠地触发事件/动作,或者在移动浏览器的情况下,如果在所需的刷新时间之后发生前台,则在执行恢复时立即触发?

谢谢!

大卫

【问题讨论】:

    标签: reactjs redux amazon-cognito redux-saga aws-cognito


    【解决方案1】:

    不需要长时间的超时,只需每隔一秒左右检查一下令牌是否已过期。

    while(true){
       yield delay(5000);
       if(yield call(checkExpiring)){
          yield relogin();
       }
    }
    

    会有很多检查,但它们不会对性能产生任何实际影响。 也就是说,我通常会编写一个 fetch 中间件来检查服务器是否回复 401/402,然后重新验证并使用新令牌重新提交。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2019-07-04
      • 2018-08-05
      • 2019-02-11
      • 1970-01-01
      • 2019-09-28
      • 1970-01-01
      • 2016-03-05
      • 2016-06-25
      相关资源
      最近更新 更多