Как правильно использовать интерцепторы в axios?

Question

[ar5]

Здравствуйте, хотел узнать у более опытных коллег как правильно использовать interceptors как при запросе так и при ответе. Можно ли управлять роутингом при запросах?

axios.interceptors.request.use(
  function(config) {
    if (!config.url.includes('Authenticate') && !config.headers.common['X-RANDOMIZE-TOKEN']) {
      const token = localStorage.getItem('token');
      if (token) {
        config.headers.common['X-RANDOMIZE-TOKEN'] = token;
        axios.defaults.headers.common['X-RANDOMIZE-TOKEN'] = token;
      } else {
        router.replace('/login');
        return config;
      }
    }
    return config;
  },
  function(error) {
    // Do something with request error
    return Promise.reject(error);
  }
);

axios.interceptors.response.use(
  response => {
    return response;
  },
  function(error) {
    EventBus.$emit('error-notify', error);
    if (error.response.status === 401) {
      router.replace('/login');
    }
    return Promise.reject(error.response);
  }
);

Comments

[Mikhail Osher]

Уточните, что значит "управлять роутингом в запросах"?

Answer 1

[Maxim Markin]

Покажу немного практик, как интерцепторы упрощают жизнь мне, да и многим, в целом.
Здесь и далее покажу именно использование интерцепторов при работе с авторизацией по JWT (токены).

1) Подстановка хедера авторизации

const createSetAuthInterceptor = options => config => {
  if (options.access) {
    config.headers.Authorization = options.access;
  } else {
    delete config.headers.Authorization;
  }
  return config;
};

const setAuthCb = createSetAuthInterceptor(store.state.auth);
axios.interceptors.request.use(setAuthCb);

Здесь мы проверям наличие доступа из стора, а точнее, наличие токена. Далее, подставляем, либо удаляем заголовок.

2) Следующая практика, это обновление токена (то, о чем вы спросили в комментарии, при окончании сессии и т.д.)

let refreshTokenPromise;

const createUpdateAuthInterceptor = (store, http) => async error => {
  const message = get(error, 'response.data.message');
  if (!['Token expired', 'Invalid token'].includes(message)) {
    return Promise.reject(error);
  }

  if (!refreshTokenPromise) {
    refreshTokenPromise = store.dispatch('refreshToken');
  }

  await refreshTokenPromise;
  refreshTokenPromise = null;

  return http(error.config);
};

const updateAuthCb = createUpdateAuthInterceptor(store, axios);
axios.interceptors.response.use(null, updateAuthCb);

Здесь мы можем видеть, что при каждом ответе проверяем наличие ошибок и если ошибка соответствует ошибке с токеном, то отправляем обновлять токен и далее снова отправляем тот же самый запрос, который к нам вернулся с ошибкой. Тут грамотно будет проверять не само сообщение об ошибке, а код ответа (401 и т.д.), но тут используется такое решение уже из за специфики бэка.

В этом же решение, вместо обновления токена, можно отправлять юзера авторизовываться самому, на страницу авторизации. Для этого, конечно же, стоит передавать не экземпляр store, а экземляр роутера, чтобы редиректить юзера. Надеюсь, помог и хоть как то наглядно показал способы применения :)

Comments

[ar5]

Да спасибо большое, в принципе очевидные способы применения. Но послушать мнения я люблю

Answer 2

[Evgeny Kulakov]

Можно - это одна из практик, т.е. когда вы делаете первый раз запрос к апи, например, чтобы получить текущего пользователя, и в случае, если получаете ошибку доступа, переходите на страницу авторизации.
Но также можно реализовать аналогичное поведение используя хуки вью роутера. Т.е. в хуке .beforeEach делаете запрос пользователя, если и тут же в исключении делаете переход на авторизацию:

store.dispatch('urrent_user')
        .then(r => {
            // next processing
        })
        .catch(e => {
             // goto login
        })

Comments

[ar5]

Это круто когда мы используем общий стор, тогда не придется делать лишних запросов. Но я понял, что все что связано с роутингом делать в хуках.

[Evgeny Kulakov]

ar5, наверное правильным будет вывод, что использовать тот или иной прием нужно в зависимости от задачи, удобства, лаконичности решения.

Answer 3

[Artem0071]

Вообще интерцепторы для другого
Например на "событие начала загрузки" можно включать индикатор загрузки, а на "событие конца загрузки" его отключать

А что на счет связи роутинга и аякса, то во вью есть хуки. Вот в них и можно обрабатывать данные когда происходят переходы по страницам

Comments

[ar5]

Наверно вы правы отчасти, но как мне при любом запросе проверить что произошла ошибка что у пользователя пропала сессия и пришла ошибка 401? и что нужно его перекинуть на страницу авторизации?