Реакция собственного обновления работает, но при следующем вызове по-прежнему используется последний токен

Ответ 1

У меня немного другая настройка в обработке. Вместо того, чтобы обрабатывать логику обновления токенов в промежуточном программном обеспечении, я определяю ее как вспомогательную функцию. Таким образом, я могу выполнить всю проверку токенов прямо перед любым сетевым запросом, если я считаю нужным, и любое действие при избыточности, которое не включает сетевой запрос, не будет нуждаться в этой функции

export const refreshToken = async () => {
  let valid = true;

  if (!validateAccessToken()) {
    try {
      //logic to refresh token
      valid = true;
    } catch (err) {
      valid = false;
    }

    return valid;
  }
  return valid;
};

const validateAccessToken = () => {
  const currentTime = new Date();

  if (
    moment(currentTime).add(10, 'm') <
    moment(jwtDecode(token).exp * 1000)
  ) {
    return true;
  }
  return false;
};

Теперь, когда у нас есть эта вспомогательная функция, я вызываю ее для всех необходимых действий при необходимости

const shouldRefreshToken = await refreshToken();
    if (!shouldRefreshToken) {
      dispatch({
        type: OPERATION_FAILED,
        payload: apiErrorGenerator({ err: { response: { status: 401 } } })
      });
    } else { 
      //...
    }

Ответ 2

В вашем промежуточном программном обеспечении вы делаете store.dispatch асинхронным, но оригинальная подпись store.dispatch является синхронной. Это может иметь серьезные побочные эффекты.

Давайте рассмотрим простое промежуточное ПО, которое регистрирует каждое действие, которое происходит в приложении, вместе с состоянием, вычисленным после него:

const logger = store => next => action => {
  console.log('dispatching', action)
  let result = next(action)
  console.log('next state', store.getState())
  return result
}

Написание вышеупомянутого промежуточного программного обеспечения по существу делает следующее:

const next = store.dispatch  // you take current version of store.dispatch
store.dispatch = function dispatchAndLog(action) {  // you change it to meet your needs
  console.log('dispatching', action)
  let result = next(action) // and you return whatever the current version is supposed to return
  console.log('next state', store.getState())
  return result
}

Рассмотрим этот пример с 3 такими промежуточными программами, соединенными вместе:

const {
  createStore,
  applyMiddleware,
  combineReducers,
  compose
} = window.Redux;

const counterReducer = (state = 0, action) => {
  switch (action.type) {
    case "INCREMENT":
      return state + 1;

    default:
      return state;
  }
};

const rootReducer = combineReducers({
  counter: counterReducer
});


const logger = store => next => action => {
  console.log("dispatching", action);
  let result = next(action);
  console.log("next state", store.getState());
  return result;
};

const logger2 = store => next => action => {
  console.log("dispatching 2", action);
  let result = next(action);
  console.log("next state 2", store.getState());
  return result;
};

const logger3 = store => next => action => {
  console.log("dispatching 3", action);
  let result = next(action);
  console.log("next state 3", store.getState());
  return result;
};

const middlewareEnhancer = applyMiddleware(logger, logger2, logger3);

const store = createStore(rootReducer, middlewareEnhancer);

store.dispatch({
  type: "INCREMENT"
});

console.log('current state', store.getState());

<script src="https://unpkg.com/[email protected]/dist/redux.js"></script>

Ответ 3

У вас есть условие гонки запросов, и нет правильного решения, которое полностью решило бы эту проблему. Следующие элементы могут быть использованы в качестве отправной точки для решения этой проблемы:

• Используйте обновление токена отдельно и дождитесь его выполнения на стороне клиента, например, отправьте обновление токена (что-то вроде GET/keepalive) в случае, если какой-либо запрос был отправлен за половину периода времени ожидания сеанса - это приведет к тому, что все запросы будут 100% авторизация (опция, которую я бы определенно использовал - она также может использоваться для отслеживания не только запросов, но и событий)
• Очистить токен после получения 401 - вы не увидите работающее приложение после перезагрузки, если предположить, что удаление действительного токена в случае граничных сценариев является положительным сценарием (Простое в реализации решение)
• Повторите запрос, который получил 401 с некоторой задержкой (на самом деле не лучший вариант)

• Принудительно обновляйте токены чаще, чем время ожидания - изменение их на 50-75% времени ожидания уменьшит количество неудачных запросов (но они все равно будут сохраняться, если пользователь простаивал в течение всего времени сеанса). Таким образом, любой действительный запрос вернет новый действующий токен, который будет использоваться вместо старого.

• Реализуйте период продления токена, когда старый токен можно посчитать действительным для периода передачи - старый токен продлен на некоторое ограниченное время, чтобы обойти проблему (звучит не очень хорошо, но это вариант по крайней мере)