Как получить новый маркер доступа с помощью наблюдаемых Redux и API маркера обновления

1656516626 kak poluchit novyj marker dostupa s pomoshhyu nablyudaemyh redux i

от Сачина Кумара

1*0nvsQXICkyKVMAq4hbYRPg
Фото от SpaceX на Unsplash

Эта статья повествует о том, как я обрабатывал код статуса 401 в ответе API. Я покажу вам, как получить новый маркер доступа с помощью маркера обновления Redux Observable в проекте React.

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

Маркер доступа

Токен доступа — это учетные данные, которые могут использоваться приложением для доступа к API. Когда срок действия маркера доступа истекает, он выбрасывает 401 код состояния в ответ на ошибку
На блок-схеме показано, как маркер доступа работает с сервером. — auth0.com

1*SSh_IFE-CEs5dUV2UGleNg
API получает маркер доступа от сервера аутентификации.

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

Обновить маркер

Токен обновления – это особый тип маркера, который можно использовать для получения обновленного маркера доступа – позволяющего получить доступ к защищенному ресурсу – в любое время. Вы можете запрашивать новые маркеры доступа, пока маркер обновления не попадет в черный список. Программа должна безопасно хранить маркеры обновления, поскольку они, по сути, позволяют пользователю оставаться аутентифицированными навсегда. — auth0.com

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

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

1*G0SuCVnu90Q5suy0qQiJaA
Вот как маркер обновления получает новый маркер с помощью маркера доступа

Вызов API маркера обновления получает новый маркер доступа от сервера аутентификации, используя маркер обновления, сохраненный во время первой аутентификации.

Мы можем лучше понять весь этот процесс посредством этой простой блок-схемы.

1*5vWZxAH-ffLyThTCwTp9ww

Наблюдаемые

Вы можете представить наблюдаемый массив, элементы которого поступают асинхронно со временем. Observables помогают управлять асинхронными данныминапример, данные, поступающие из серверной службы.

В RxJS это может оказаться достаточно сложным во время игры с наблюдаемыми потоками. Не беспокойтесь — мы собираемся упростить это с помощью простых фрагментов кода.

Давайте начнем с простого вызова API в redux-observable. Вот как выглядит простая функция для API получения:

Решение

Теперь мы вооружились основными понятиями. Давайте посмотрим, как мы можем обрабатывать код статуса 401 (invalid_token или session expired) в ответе API. Мы также увидим, как можно получить новый маркер доступа с помощью маркера обновления в Redux Observable.

Нам нужно внести два изменения в вышеупомянутую функцию:

  1. Поверните наш вызов API в Observables.defer(). Мы хотим получить эту функцию для повторного вызова, когда будет получен новый действительный маркер доступа.
  2. Когда мы получаем статус 401 в ошибке catch. Нам нужно совершить вызов API, чтобы получить новый маркер доступа. Мы используем маркер обновления, сохраненный при первой успешной аутентификации.

Давайте посмотрим на различия между двумя функциями:

  1. Функция catch всегда дает источник родительского потока. Мы можем использовать это, чтобы снова запустить поток, не удавшийся из-за недействительного маркера доступа.
  2. Теперь начните новый поток событий, чтобы прослушать события успеха маркера обновления. Мы останавливаемся, когда API маркера обновления не работает (используйте для этого takeUntil).
  3. Теперь убедитесь, что вы используете брать оператор, чтобы всегда получать первое событие потока. Если у вас есть несколько потоков, ваш исходный поток может быть скомпрометирован.
  4. При получении нового маркера доступа используйте mergeMap, чтобы объединить источник предыдущего потока. Мы снова объединим его с родительским потоком, и он вызовет функцию get data с новым маркером доступа.
  5. Теперь вам может быть интересно, как работает слияние. Таким образом, merge независимо вызывает и запускает собственный поток, чтобы получить новый маркер доступа с помощью маркера обновления (посмотрите следующую функцию). Когда появится маркер обновления, он перейдет к шаг 2 и так дальше.

Мы можем использовать этот подход для обработки более особых случаев для разных кодов статуса, а также 500, 403.

ProTip: обязательно проверьте условие бесконечного цикла, если API маркера обновления дает 401. Вы можете поддерживать счетчик при каждом вызове маркера обновления. Если количество превышает, остановите поток. Затем выполните любую обработку ошибок на нем, например, показывайте сообщение о произошедшей ошибке и выйдите из пользователя.

Вывод

Мы реализовали недействительный обработчик маркеров, используя API маркера обновления из Redux-observables в React. Этот подход можно использовать для обработки других специальных случаев API.

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

Некоторые полезные ресурсы

  1. https://redux-observable.js.org/
  2. https://rxjs-dev.firebaseapp.com/api
  3. https://rxjs-dev.firebaseapp.com/api/index/function/defer
  4. https://rxjs-dev.firebaseapp.com/api/index/function/merge

Добавить комментарий

Ваш адрес email не будет опубликован.