Аутентификация токена с помощью Volley

Если у меня есть сервер, на котором я аутентифицируюсь с именем пользователя / паролем и получаю токен аутентификации для последующих запросов, какой будет лучший подход к решению этой проблемы?

Поток должен быть таким: – Запрос на запуск – Если у нас нет токена аутентификации – получите его с именем пользователя и паролем – Сделайте запрос с токеном auth – Если запрос не сработал, потому что токен истек, получите новый токен аутентификации с именем пользователя и паролем – Запрос повторной попытки с новым токеном auth – Завершить

Я заметил, что у Volley уже есть что-то, что может решить эту проблему – Authenticator https://android.googlesource.com/platform/frameworks/support/+/4474bc11f64b2b274ca6db5a1e23e8c1d143d5fa/volley/src/com/android/volley/toolbox/Authenticator .java Он содержит методы getAuthToken () и invalidateAuthToken (), которые будут именно то, что я хочу. Но кажется, что он никогда не используется в библиотеке вообще.

Я использовал залп для системы аутентификации с использованием токенов Longlive (LLT) и Shortlive (SLT).

Я сделал это вручную, но на самом деле это было не так много, как только вы все выложили.

Попросите все защищенные запросы подкласса baseSecureRequest, которые могут обрабатывать этот механизм токена, общий для всего защищенного запроса, в его onResponse () и onErrorResponse ().

Он становится маленьким стилем node.js, где запросы отправляют другие запросы и ждут обратные вызовы.


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

Сценарий A

  • Мы пытаемся отправить безопасный запрос. Мы замечаем, что у нас нет SLT в памяти, поэтому сделайте TokenRequest.
  • TokenRequest onResponse () сохраняет этот токен в память (пусть один синтаксический менеджер сеанса удерживает на нем или аналогичный omni-present класс)
  • Теперь обратимся к исходному объекту запроса конкретного класса, чтобы продолжить новый обновленный токен.

Сценарий B

  • Мы отправляем безопасный запрос, но наш SLT устарел (истек)

  • Сервер возвращает код ошибки или msg, который вы можете поймать в общем onErrorResponse () вашего baseSecureRequest.

  • В этом onError () вы отправляете объект refreshTokenRequest (), который пытается обновить SLT в памяти, запросив новый SLT с сервера с использованием LLT.

  • OnResponse () refreshTokenRequest теперь может возвращать исходный запрос для повторной отправки.

  • Однако onErrorResponse (), вероятно, должен отказаться от всего, потому что вероятность того, что это не ошибка подключения, – это ошибка, вызванная недействительным LLT. Если вы продолжаете пытаться обновиться с плохим LLT, вы никогда не выберетесь.
  1. Возможно, вы захотите использовать API AccountManager в Android для аутентификации и авторизации. Вы можете следить за блогами здесь .
  2. Для реализации серверной стороны OAuth 2.0 вы можете прочитать здесь проект IETF V2-31.
  3. Для лучшего понимания OAuth 2.0 вы можете прочитать блог Nitesh Kumar здесь .
  4. Для реализации на стороне сервера OAuth 2.0 вы можете разблокировать сервер Apis Autherization Server в Github.
  5. Дополнительную возможность реализации можно найти на веб-сайте OAuth 2.0.

Вы видели это сообщение в блоге? https://smaspe.github.io/2013/06/06/volley-part2.html

Демонстрирует простой способ переопределения объекта запроса для использования токенов Twitter.