Вопрос по facebook, facebook-access-token, ios, facebook-graph-api, mobile – Как справиться с потерей Facebook Facebook offline_access, когда вы используете токен как в приложении для iOS, так и на сервере

11

Facebook & APOS; sнеодобрение изoffline_access разрешение поступает в мае 2012 года, и документация не дает нам достаточной информации о том, как с ним обращаться.

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

Client

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

Server

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

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

Problems

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

Questions

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

(акцент мой)

When you obtain an access token from Facebook, it will be valid immediately and usable in requests to the API for some time period defined by Facebook. After that period has elapsed, the access token is considered to have expired and the user will need to be authenticated again in order for your app to obtain a fresh access token. The duration for which a given access token is valid depends on how it was generated.

There are also events which may cause an access token to become invalid before its expected expiry time. Such events include the user changing their password, an application refreshing it's App Secret. Dealing with varying access token expiry times, and handling the case when an access token becomes invalid before its expected expiry time is essential for building robust social experiences.

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

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

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

Can I exchange my 60 day access token for a new 60 day access token?

No, sorry you cannot. You can only exchange a valid (meaning current) user access token for an extended one. You cannot extend an already extended access token.

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

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

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

Я добавил четвертый вопрос в качестве D в своем первоначальном вопросе. TMC
@TMC вместо "опроса" Периодически для друзей, добавляющих приложение, вы можете нажать & quot; эти данные, когда вы получаете нового пользователя? Если это ваше единственное использование маркеров автономного доступа, то это может быть альтернативным обходным решением для реализации нового материала offline_access. logan
Я также ищу ответ Б. В данный момент FB предоставляет мне токены доступа, которые работают в iOS 2 часа. Означает ли это также, что я должен прекратить попытки заставить [Facebook exteAccessToken] и [Facebook exteAccessTokenIfNeeded] работать так, как теперь они больше не работают? nbransby
@ TMC Извините, вы правы. Если два человека используют ваше приложение раньше, чем перед друзьями, то вам придется опросить. logan
@logan: Наш сервер периодически опрашивает FB, чтобы проверить изменения в списке друзей, а также отслеживает нашу систему, чтобы узнать, зарегистрировался ли кто-либо из ваших друзей. Затем мы делаем автоматическое отслеживание между друзьями, чтобы сделать приложение более привлекательным. Я не вижу, как будут работать push-данные. TMC

Ваш Ответ

2   ответа
0

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

16

Overview

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

Я не работаю на Facebook, но вот мои выводы из игры с графиком API api.

General Solution

  1. Whenever a user signs in, take their access token and immediately extend/refresh it, and save it
  2. Record the expiration date of the access token
  3. When an access token expires (either from the recorded date, or a graph API exception telling you so), then notify the user that you don't have access, and ask them to sign in again.

Answers

A. When you authenticate through the newest Facebook iOS SDK, what is the default lifetime of the access token you get? This document says an extended token request will give you one that lasts 60 days. This other document talks about the first access token request and mentions varying validities but it's unclear and does it talk about specific validity times:

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

  1. The first sign-in grants you approximately two hours
  2. By refreshing the access token, you can get up to 60 days
  3. If the user doesn't sign in to those 60 days, there is no way to get access for longer without having them sign in.
  4. If the user de-authorizes your app, that 60 day windows ends immediately, and you will no longer have access.

B. For the client, now that the access token isn't necessarily long lived, is the right approach for us to: Let use login through FB, then detect whenever the access token is expired. If it is, then call into FB iOS SDK to re-authentication/re-authorize? (this should just trigger user to bounce out to FB iOS app, and in most cases come immediately back to our app with a new access token).

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

C. According to this blog post I found, you can only extend an access token once. On the client, I can just handle this by prompting a re-authentication/re-authorization as I mentioned in Question B. However, this doesn't work on our server. We could certainly have the server renew it once to 60 days, but what happens on the 61st day? The server just stops being able to sync the friend's list?

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

D. It seems to make sense to check the validity of the FB access token every time the app starts or re-hydrates from sleep. What is the best way for our iOS app to check this? Is there a recommended endpoint to call to validate a token? Should we just call into https://graph.facebook.com/me passing the access token and checking the response?

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

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

Tid Bits

  • When you "refresh" an access token, a new access token will be returned. The response looks like: access_token=TOKEN&expires=5183912
  • You can only "refresh" an access token once. If you try to "refresh" the long-lived token returned from a previous call, it will return the same token, but doesn't throw an exception unless the token has expired. (in other words, you can safely try to refresh your token)
  • The default access token length seems to be around 2 hours
  • If you "refresh" an access token, that new access tokens seems to be the one that you'll get from the facebook API afterwards (instead of returning the original, short-lived access token)

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

Вы также можете сообщить пользователю с помощью push-уведомления, что ему нужно снова войти в систему. Это, вероятно, даст вам более быстрый ответ / вход, так как не многие люди часто проверяют электронную почту.
Нет, я имел в виду, что сервер может отправлять push-уведомление клиенту, поэтому пользователю предлагается снова открыть приложение и войти в систему. Я не знаю, что такое запросы от приложения к пользователю. Читая об этом сейчас.
Он все еще отображается как электронная почта, но в любом случае +1 за хороший, подробный ответ.
Ты имеешь ввидуapp-to-user requests? Они тоже могут быть полезны.
Хорошая точка зрения. Push-уведомления не работают для моего веб-приложения, но я обновил свой ответ и оставил уведомляющую пользовательскую часть разработчику.

Похожие вопросы