Когда я должен загрузить новый токен доступа?

Question

Мое приложение использует авторизацию на Javascript SDK на стороне клиента, а для авторизованного пользовательского приложения извлекает токен доступа из API Facebook, используя cookie facebook с подписанным запросом и предоставляет code и сохраняет его в базе данных.

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

Как я понимаю, теперь у нее есть новый токен доступа, и приложение должно загрузить его из Facebook. Но как я могу понять, когда я должен проверить новый токен? Проверка каждого запроса с помощью cookie facebook не работает, потому что для каждого пользователя требуется несколько запросов в секунду (событие, если она не изменила пароль). Или, может быть, я что-то делаю неправильно?

Я имею в виду:

• Я Авторизованный пользователь на стороне клиента
• Я печенье с подписью запроса
• Подпись запроса достаточно симпатично, чтобы разрешить пользователю на стороне сервера (проверки учетных данных пользователя)
• Я могу получить access token, обратившись к Facebook API, в любое время, когда пользователь запрашивает мое приложение (потому что мне нужен code из подписанного запроса). Итак, я делаю это, когда я не сохранил access token или существующий access token истек.
• access token просто хранятся в базе данных, и может быть использован в любое время, в другом потоке, может быть, через несколько минут (в среднее у нас нет запроса пользователя и печенья с подписанным запросом)
• Что делать, если хранить access token не истекли, но утратившие на стороне facebook? Мне нужно получить новый access token, но cookie ушел в этот момент.

В настоящее время я вижу только один путь: магазин code из подписанного запроса в Databse, и когда мы обнаружили, что у нас есть недопустимый access token, попробуйте загрузить его. Но я уверен, что это правильный способ и не так много полезен для большинства случаев.

Answer 1

У вас есть токен-клиент и токен сервера, клиент недолговечен (несколько часов), а сервер долговечен (60 дней).

Маркер на стороне клиента не должно беспокоить вас слишком много, так как вы можете получить новый легко, как говорится в «Handling Invalid and Expired Access Tokens» руководство:

Desktop Web и мобильных веб-приложений, которые осуществляют проверку подлинности с Javascript SDK

вызов FB.getLoginStatus() или обеспечение состояния: истина устанавливается при вызова FB.init() означает, что в следующий раз, когда пользователь попадает на ваш применения и подписывается в Facebook, в объект authResponse передаются в результате этих вызовов, будет содержать новый действительный токен доступа .

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

Маркер на стороне сервера, который вы будете упорствовать в БД, не может быть так же легко воспроизводится, пользователь должен быть направлен к диалогу Идент снова:

Desktop Web и мобильных устройств веб-приложения, которые реализуют аутентификации на стороне сервера потока

Чтобы получить свежий маркер доступа в этом случае вы должны передать пользователю через весь серверный поток снова: то есть получить код и обмен его на новый токен доступа.

Однако, предполагая, что пользователь не де разрешенным приложение, при перенаправлении пользователя в OAuth Dialog, пользователь не будет предложено повторно авторизовать приложение, и будет немедленно перенаправлены на redirect_uri. Это означает, что процесс повторной аутентификации может выглядеть прозрачным для пользователя.

Вы можете, конечно же, отправить токен клиента на сервер и продолжать это, но это довольно бессмысленно, поскольку он недолговечен. Другим вариантом является использование new endpoint to extend a действительного клиентского токена на стороне сервера, а затем сохранение этого.

Что касается «как узнать, когда вы получаете новый токен», на стороне сервера, когда вы делаете запросы api, просто проверяйте ответ и посмотрите, вернулась ли ошибка, и если да, то что это (есть список в первый url, который я добавил). Если токен истек, просто отправьте пользователя в диалоговое окно auth (вы можете вернуть какой-то код на клиентскую сторону и сделать это оттуда), а затем сохранить новый токен в db.

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

---

Редактировать

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

Что вы должны сделать:

На стороне сервера вы должны следовать инструкциям в Server-Side auth guide, получить «код» и обменять его с маркером. У этого токена будет 60 дней.

Используйте этот токен, который вы храните в своем db, по мере необходимости (другие темы, а что нет), и когда вы получаете сообщение об ошибке из facebook, говорящее, что токен истекает, просто перейдите на страницу диалога auth ,

Вы не можете использовать «код», чтобы получить более одного токена, так что это вам не поможет. Если пользовательский сеанс (и токен) получил недействительность (по разным причинам), вы все равно получите сообщение об ошибке из facebook при попытке выполнить запрос api, когда это произойдет, просто снова отправьте пользователя в диалоговое окно auth.