Часть, которую вы пропустили, не является частью адаптера синхронизации. Это AbstractAccountAuthenticator. Это класс, который на самом деле имеет дело с паролем пользователя и передачей его на сервер, и его нужно будет написать так, чтобы он был в паре с рассматриваемым сервером.
Как:
Прежде всего, как работает процесс?
- Пользователь вводит имя пользователя и пароль на странице Настройки-> Аккаунты и синхронизация.
- (Позже ...) Процесс синхронизации начинается.
- SyncAdapter вызывает blockingGetAuthToken ()
- AccountAuthenticator запускается.
- AccountAuthenticator использует обычную проверку подлинности http (или, в идеале, https) для подключения к серверу и после проверки подлинности запрашивает «токен» у сервера. Этот токен представляет собой большое (скажем, 128-битное) случайное число, которое можно получить только с сервера, если вы вошли в систему с использованием аутентификации на основе пароля.
- AccountAutenticator кэширует токен, а затем возвращает токен в SyncAdapter.
- SyncAdapter пытается получить доступ к содержимому на сервере и передает токен как часть заголовков http в своих запросах.
- Сервер принимает токен вместо обычного http-auth и разрешает обработку запроса.
- Будущие попытки синхронизации в конечном итоге пропустят большую часть этого процесса. При следующих попытках синхронизации, когда SyncAdapter вызывает blockingGetAuthToken (), AccountAuthenticator просто возвращает кэшированный токен, не требуя повторной аутентификации.
Таким образом, этот токен является ограниченным использованием - через некоторое время сервер откажется принять его. В этот момент SyncAdapter пытается использовать токен и получает ошибку аутентификации. И что тогда?
- SyncAdapter вызывает invalidateToken (токен) и передает (токен с истекшим сроком действия) обратно в AccountAuthenticator.
- AccountAuthenticator находит токен в своем кэше и выбрасывает его.
- При следующем вызове blockingGetAuthToken () AccountAuthenticator установит связь с сервером и получит новый токен. Оттуда синхронизация происходит нормально.
Почему?
Так что есть несколько преимуществ.
- Обычный http auth передает пароль в виде открытого текста через Интернет. Если используются токены, пароль отправляется только один раз, токен много раз. Это несколько снижает вероятность взлома пароля.
- Проверка подлинности https позволяет избежать проблемы с открытым текстом, но может быть дорогостоящим с точки зрения мобильного соединения. Использование токенов позволяет использовать более легкие http-соединения для вызовов сервера, которые фактически переносят данные, а издержки https видны только при первом запросе при получении токена.
- Разделение - AccountAuthenticator знает фактический пароль пользователя. SyncAdapter только получает доступ к токену и никогда не узнает пароль. Это важно, скажем, для Google, потому что оно позволяет стороннему приложению использовать для аутентификации учетную запись gmail и пароль, без стороннего приложения (которое может быть вредоносным), чтобы получить пароль (и переслать его коварному наэр-доу). -на)
Действительно:
Жетоны опасны. Любой, кто получит доступ к токену, может войти как вы. Итак, хорошие практики здесь:
- Сервер должен истечь токены пользователя по истечении определенного периода времени. Больше паранойи - короче время ожидания.
- Сервер должен истечь все токены пользователя всякий раз, когда пользователь меняет свой пароль.
- Сервер, вероятно, не истекает токен, назначенный веб-устройству, если пользователь на
веб-интерфейс выходит из системы. На самом деле для токенов не существует концепции «выхода из системы».
- Сервер должен рассмотреть возможность привязки токена к IP-адресу, который сначала запрашивает его, а затем отказаться от аутентификации (но не обязательно с истечением срока действия) токена, если впоследствии другой IP-адрес попытается использовать этот токен.Если вы сделаете это, сервер определенно должен будет иметь возможность создавать несколько токенов на пользователя (один токен на пользователя: комбинация ipaddress) - рассмотрите пользователя с двумя мобильными устройствами - без этого, каждый раз, когда одна синхронизация будет аннулированазнак другого.Также учтите, что два устройства оба на домашней Wi-Fi (совместно используют один IP-адрес за маршрутизатором, а затем одно устройство уходит и начинает использовать мобильную сеть - вот почему вы можете выбрать, чтобы не истек срок действия, поэтому устройство, все еще сидя дома, может продолжать использоватьтокен. Однако одно устройство, которое выходит в роуминг, увидит ошибку аутентификации и установит свой собственный новый токен. Когда он вернется домой, сервер должен обязательно предоставить тот же токен, который уже установлен для этого IP-адреса.)
- В зависимости от вашего уровня паранойи, все равно принимайте только токены авторизации через https. Firesheep является отличным примером того, что может получить украденный токен авторизации.Если у вас есть конфиденциальные данные, вы должны принимать только через https.Кроме того, даже если у вас нет данных, чувствительных к пользователю, вы можете рассмотреть возможность написания протокола, который требует https для изменения БД и разрешения чтения http.