Как справиться с отказом Facebook от офлайн_access, когда вы используете токен как в приложении iOS, так и на сервере

Facebook неодобрение в offline_access разрешения приходит май 2012 и документация не дает нам достаточно информации о том, как справиться с этим.

У нас есть приложение iOS и соответствующая служба, которая его поддерживает и интегрируется с Facebook в глубокой форме, чтобы использовать список друзей пользователя внутри приложения (поэтому, если ваши друзья FB также используют приложение, вы можете легко подключиться). Это похоже на то, как работают все социальные приложения, поэтому здесь ничего особенного.

клиент

Наше приложение использует Facebook iOS SDK, чтобы позволить пользователю войти в систему, и в настоящее время мы запрашиваем offline_access. Токен сохраняется в нашем приложении iOS, но также отправляется на наш сервер, где он сохраняется. Клиент действует от имени пользователя для публикации обновлений в publish_stream новостей пользователя (мы также запрашиваем разрешение publish_stream).

сервер

Наш сервер периодически проверяет, могут ли пользователи FB пользователей использовать наше приложение. В следующий раз, когда пользователь заходит, мы показываем контент и отношения определенным образом, чтобы продвигать друзей этого пользователя. Сервер также действует от имени пользователя для периодического подключения к API-интерфейсу графа и получения списка текущих друзей пользователя. Таким образом, мы можем учитывать изменения в пользовательских отношениях и отражать их в нашем приложении. Мы делаем это, когда пользователь в настоящее время не использует приложение, чтобы иметь лучший опыт при следующем использовании. Чтобы включить это, наше приложение iOS отправляет токен доступа на наш сервер, который он использует, и почему мы запрашиваем offline_access.

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

Проблемы

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

Вопросов

A. Когда вы проверяете подлинность через новейший SDK iOS для Facebook, каково время жизни маркера доступа по умолчанию, которое вы получаете? В этом документе говорится, что расширенный запрос токена даст вам тот, который длится 60 дней. В этом другом документе говорится о первом запросе доступа к токену и упоминается о разных действиях, но он неясен и говорит о конкретных сроках действия:

(акцент мой)

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

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

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

Позвольте использовать логин через FB, а затем обнаруживать, когда токен доступа истек. Если это так, то обратитесь в FB iOS SDK для повторной аутентификации/повторной авторизации? (это должно просто заставить пользователя отскакивать в приложение FB iOS и в большинстве случаев сразу же возвращается к нашему приложению с новым токеном доступа).

C. В соответствии с этим сообщением в блоге, которое я нашел, вы можете только продлить токен доступа один раз:

Могу ли я обменять токен доступа на 60 дней на новый токен доступа на 60 дней?

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

На клиенте я могу просто справиться с этим, предложив повторную аутентификацию/повторную авторизацию, как я упоминал в вопросе B. Однако это не работает на нашем сервере. Разумеется, сервер может обновить его раз в 60 дней, но что произойдет в 61-й день? Сервер просто перестает синхронизировать список друзей?

D. Кажется, имеет смысл проверять достоверность токена доступа FB каждый раз, когда приложение запускается или повторно увлажняется от сна. Каков наилучший способ для нашего приложения iOS проверить это? Есть ли рекомендованная конечная точка для вызова проверки токена? Должны ли мы просто позвонить в https://graph.facebook.com/me передав токен доступа и проверим ответ?

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

Ответ 1

обзор

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

Я не работаю для facebook, но вот мои выводы от игры с графикой facebook api.

Общее решение

Всякий раз, когда пользователь подписывается, забирает свой токен доступа и немедленно продлевает/обновляет его и сохраняет его
Записать дату истечения срока действия токена доступа
Когда токен доступа истекает (либо с записанной даты, либо из-за исключения API-интерфейса графика), сообщите пользователю, что у вас нет доступа, и попросите их снова войти в систему.

ответы

A. Когда вы проверяете подлинность через новейший SDK iOS для Facebook, каково время жизни маркера доступа по умолчанию, которое вы получаете? В этом документе говорится, что расширенный запрос токена даст вам тот, который длится 60 дней. В этом другом документе говорится о первом запросе доступа к токену и упоминается о разных действиях, но он неясен и говорит о конкретных сроках действия:

Вот как это работает:

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

B. Для клиента теперь, когда токен доступа не обязательно долговечен, является правильным подходом для нас: позволить использовать логин через FB, а затем обнаруживать, когда токен доступа истек. Если это так, то обратитесь в FB iOS SDK для повторной аутентификации/повторной авторизации? (это должно просто заставить пользователя отскакивать в приложение FB iOS и в большинстве случаев сразу же возвращается к нашему приложению с новым токеном доступа).

Если токен доступа пользователей истек, ваш единственный вариант - заставить их пройти через цикл входа, как вы говорите.

C. В соответствии с этим сообщением в блоге, которое я нашел, вы можете продлить токен доступа только один раз. На клиенте я могу просто справиться с этим, предложив повторную аутентификацию/повторную авторизацию, как я упоминал в вопросе B. Однако это не работает на нашем сервере. Разумеется, сервер может обновить его раз в 60 дней, но что произойдет в 61-й день? Сервер просто перестает синхронизировать список друзей?

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

D. Кажется, имеет смысл проверять достоверность токена доступа FB каждый раз, когда приложение запускается или повторно увлажняется от сна. Каков наилучший способ для нашего приложения iOS проверить это? Есть ли рекомендованная конечная точка для вызова проверки токена? Должны ли мы просто позвонить в https://graph.facebook.com/me, передав токен доступа и проверим ответ?

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

Я думаю, что ваше предложение о хите https://graph.facebook.com/me ~~будет работать отлично,~~ это то, что они рекомендуют в своем примере. Фактически, я мог бы использовать этот подход в своем приложении в качестве активного способа проверки токена доступа.

Tid Bits

Когда вы "обновляете" токен доступа, будет возвращен новый токен доступа. Ответ выглядит так: access_token=TOKEN&expires=5183912
Вы можете только "обновить" токен доступа один раз. Если вы попытаетесь "обновить" долгоживущий токен, возвращенный из предыдущего вызова, он вернет тот же токен, но не выдает исключение, если токен не истек. (другими словами, вы можете спокойно попытаться обновить свой токен)
Длина токена доступа по умолчанию составляет около 2 часов
Если вы обновляете токен доступа, эти новые токены доступа, по-видимому, будут получены из API facebook (вместо того, чтобы возвращать оригинальный токен с недолгосрочным доступом)

Кроме того, если вы хотите поиграть, эти инструменты позволяют легко проверить ваш вариант использования в браузере, прежде чем хоронить его в коде:

Graph API Explorer - для создания и получения токенов доступа
Debug Console - для проверки даты истечения срока годности токенов до/после обновления
Обновить конечную точку - для ручного тестирования, расширяющего токены

Ответ 2

Отличный ответ, одно важное дополнение: токен по умолчанию длится от 1 до 2 часов. Вы получаете оставшийся час, в течение которого пользователь подписывается, плюс 1 полный час. Например, если пользователь подписывается в 15:45, токен доступа истекает в 17:00. Чтобы быть безопасным, разработчики должны предположить, что он длится всего 1 час.