Как мне работать с аутентификацией на стороне сервера сейчас, когда offline_access устарела?

Question

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

Я прочитал всю документацию вокруг https://developers.facebook.com/roadmap/offline-access-removal/

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

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

https://graph.facebook.com/oauth/authorize?client_id=APP_ID&scope=publish_stream,manage_pages,offline_access&response_type=token&redirect_uri=MY_REDIRECT_URL

Исторически мое приложение затем сохраняет сгенерированный токен доступа (срок действия которого не истек) в базе данных. Теперь, с устареванием offline_access, этот токен доступа теперь является недолговечным токеном, который, очевидно, можно заменить на 60-дневный токен, перейдя в

https://graph.facebook.com/oauth/access_token?client_id=AP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=OLD_SHORT_TOKEN

Поэтому я могу перейти по указанному выше URL и сохранить возвращенный маркер долгосрочного доступа. Все идет нормально. Вот проблема....

Как указывалось ранее, мое приложение может не пытаться публиковать сообщения в Facebook в течение нескольких месяцев или лет (т.е. после истечения срока действия моего 60-дневного токена). Согласно документации, я могу использовать опцию fb_exchange_token для обмена короткоживущего токена на токен на 60 дней, но я не могу обменять токен на 60 дней, срок действия которого истекает, на новый токен на 60 дней. И единственный способ получить новый краткосрочный токен - найти пользователя, который войдет в систему и сгенерирует его. Это моя проблема. Насколько я понимаю, я не могу получить новый краткосрочный токен без повторного входа пользователя.

Я пытался придумать аналогию, которую было бы проще понять, и это лучшее, что я придумал.

Предположим, у меня есть скрипт bash, который запускается в cron каждые 90 дней, чтобы опубликовать сообщение на странице компании в Facebook, объявляющее о доступности квартальных отчетов. В новом устаревшем мире offline_access, как я могу заставить эту работу cron работать? Единственные пользовательские данные, которые я храню, это токен доступа на 60 дней, а скрипт bash не имеет пользовательского интерфейса.

Если бы я принял самое хакерское решение и потребовал, чтобы человек, который установил наше приложение, включил свое имя пользователя и пароль fb как часть установки, как бы это работало. Есть ли способ предоставить имя пользователя и пароль для API api, а затем смоделировать входящие и исходящие потоки кликов с помощью чего-то вроде HttpClient?

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

Извините, если это многословное сообщение. Я попытался получить всю информацию, чтобы кто-то мог помочь, не задавая дополнительные вопросы.

Answer 1

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

Ну, в этом весь смысл удаления offline_access...

Предположим, у меня есть скрипт bash, который запускается в cron каждые 90 дней, чтобы опубликовать сообщение на странице компании в Facebook, объявляющее о доступности квартальных отчетов. В новом устаревшем мире offline_access, как я могу заставить эту работу cron работать?

С токеном доступа к странице вместо токена доступа пользователя - токены доступа к странице не устаревают (до тех пор, пока пользователь, от которого вы их получили, не меняет свой пароль или полностью покидает платформу).

Если бы я принял самое хакерское решение и потребовал, чтобы человек, который установил наше приложение, включил свое имя пользователя и пароль fb как часть установки, как бы это работало.

Это было бы явным нарушением политик платформы FB. Вы не должны даже думать об этом.

В идеале, если бы у меня было что-то вроде опции fb_exchange_token, которая могла бы обменять 60-дневный токен на новый 60-дневный токен […]

Опять же, если бы Facebook захотел, чтобы это было возможно, им не нужно было бы сначала удалять offline_access.