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

17

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

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

Я заметил, что у Volley уже есть что-то, что может решить эту проблему - Authenticator Ссылка Он содержит методы getAuthToken () и invalidateAuthToken (), которые будут именно то, что я хочу. Но кажется, что он никогда не используется в библиотеке вообще.

    
задан MantasV 01.07.2013 в 10:42
источник
  • Я только что проверил источники, и похоже, что вы - Authenticator не используется в коде. Поэтому, вероятно, вам придется делать это вручную. –  negersiu 01.07.2013 в 23:08
  • Да. Тем временем я скопировал класс BasicNetwork и внедрил там настройки для аутентификации. –  MantasV 04.07.2013 в 16:57
  • можете ли вы опубликовать, как вы это сделали в ответ, пожалуйста –  M-WaJeEh 15.08.2013 в 12:41

4 ответа

11

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

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

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

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

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

Сценарий A

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

Сценарий B

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

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

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

  • onResponse () refreshTokenRequest теперь может возвращать оригинальный запрос на повторную отправку.

  • однако onErrorResponse () должен, вероятно, отказаться от всего, потому что есть шансы все, что не является ошибкой подключения - это ошибка, вызванная недействительный LLT. Если вы продолжаете пытаться обновиться с плохой LLT, вы никогда не выберетесь.
ответ дан mjw 24.08.2013 в 05:58
  • @mjw ... у вас есть пример кода для этого? –  Saad Farooq 06.12.2013 в 05:50
  • Я второй это движение, любой код? –  CQM 29.01.2014 в 17:43
  • Я согласен. Можем ли мы получить пример кода для этого? –  HariKJ 30.07.2014 в 08:47
  • Я не согласен. onErrorResponse слишком поздно для обновления токена, потому что запрос будет считаться недействительным, независимо от того, что вы делаете. Правильное место для запроса нового токена будет в настраиваемом классе RetryPolicy. Политике повторного запроса будет предложено подготовиться к повторной попытке в 2 случаях: 1. Тайм-аут 2. AuthFailureError - это то, что вы хотите. –  Avraham Shukron 31.10.2014 в 15:03
  • Это недействительное решение. К тому времени, когда волейбол возвращает ошибку, он уже повторил ваш запрос. Правильное место для этого - написать пользовательскую политику повтора. Предположим, у вас есть 3 потока для вашего запроса API. Это означает, что из вашей сетевой очереди можно теоретически иметь 3 запроса параллельно. Теперь, если истечет срок действия SLT, вы получите три отказа в разное время. Это означает, что вы повторите попытку обновления RefreshTokenRequest либо старым SLT, либо продолжите повторную попытку с новыми токенами, даже если у вас есть действительный токен. –  SaKet 26.10.2015 в 19:38
1
  1. Возможно, вы захотите использовать API AccountManager в Android для аутентификации и авторизации. Вы можете следить за блогом здесь .
  2. Для реализации на стороне сервера OAuth 2.0 вы можете прочитать проект IETF V2-31 здесь .
  3. Для лучшего понимания OAuth 2.0 вы можете прочитать блог Nitesh Kumar here .
  4. Для реализации OAuth 2.0 на стороне сервера вы можете использовать Apis Autherization Server в Github.
  5. Дополнительную опцию реализации можно найти на веб-сайте OAuth 2.0 здесь .
ответ дан Gaurav Agarwal 10.07.2013 в 21:30
  • Спасибо за ответ, но мои вопросы касаются, в частности, Volley. Речь идет не о том, как делать авторизацию, а как интегрировать ее с Volley –  MantasV 21.07.2013 в 22:50
  • AndroidAuthenticator, похоже, использует accountManager, но я не уверен, как мы должны использовать AndroidAuthenticator. –  Pierre-Antoine 08.12.2013 в 16:34
1

Вы видели этот пост в блоге? Ссылка

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

@Override
    public Map<String, String> getHeaders() throws AuthFailureError {
        Map<String, String> headers = new HashMap<String, String>();
        String auth = "Basic "
                + Base64.encodeToString((TwitterValues.CONSUMER_KEY 
                + ":" + TwitterValues.CONSUMER_SECRET).getBytes(),
                        Base64.NO_WRAP);
        headers.put("Authorization", auth);
        return headers;
    }
    
ответ дан cbrulak 04.01.2015 в 14:22
  • Ссылка вниз. У вас есть еще одна такая запись? –  davidbonachera 20.01.2016 в 17:40
  • @davidbonachera связанный блог недавно был перемещен (и переименован). Я обновил ссылку. –  njzk2 04.03.2016 в 05:39
  • Хотя эта ссылка может ответить на вопрос, лучше включить здесь основные части ответа и предоставить ссылку для справки. Ответные ссылки могут стать недействительными, если связанная страница изменится. - Из обзора –  Eugen Konkov 14.02.2018 в 16:27
  • @EugenKonkov хороший звонок. Обновлено. –  cbrulak 14.02.2018 в 16:29
-2

getToken() не удалось. Ошибка статуса BAD_AUTHENTICATION

Я также столкнулся с той же проблемой.

Решение. Убедитесь, что устройство зарегистрировалось в вашей учетной записи Google.

    
ответ дан prajakta waikar 14.02.2018 в 15:57
  • Предполагается ли это, что это ответ или новый вопрос? –  Baum mit Augen 14.02.2018 в 23:42