0

随着访问令牌即将消亡，我希望有人可以帮助解决我相当独特的问题。

我已阅读有关https://developers.facebook.com/roadmap/offline-access-removal/的所有文档

而且我认为我的应用程序属于一个完全不同的类别。我们有一个应用程序很少向 facebook 发布消息（它们之间可能是几年），但这些帖子非常重要。这些发布是在运行 tomcat 的 JVM 中启动的，但不一定由用户所做的任何事情启动。

当用户安装他们的应用程序版本时，他们使用浏览器通过正常的服务器端身份验证过程

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 的弃用，这个访问令牌现在是一个短期令牌，显然可以通过转到

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 并存储返回的长期访问令牌。到现在为止还挺好。这就是问题所在......

如前所述，我的应用程序可能在几个月或几年内（即在我的 60 天令牌过期后）都不会尝试发布到 facebook。根据文档，我可以使用 fb_exchange_token 选项将短期令牌交换为 60 天令牌，但我无法将即将到期的 60 天令牌交换为新的 60 天令牌。我发现获得新的短期令牌的唯一方法是让用户登录并生成它。那是我的问题。据我了解，如果没有用户再次登录，我将无法获得新的短期令牌。

我试图想一个更容易理解的类比，这是我想出的最好的。

假设我有一个 bash 脚本，该脚本每 90 天在 cron 中运行一次，以向公司的 facebook 页面发布消息，宣布季度报告可用。在新的、已弃用的 offline_access 世界中，我怎样才能使这个 cron 工作正常工作？我存储的唯一客户特定数据是 60 天访问令牌，而 bash 脚本没有用户界面。

如果我做了最骇人听闻的解决方案，并要求安装我们的应用程序的人在安装过程中包含他们的 fb 用户名和密码，那将如何工作。有没有办法向图形 api 提供用户名和密码，然后使用 HttpClient 之类的东西模拟登录和 oauth 点击流？

理想情况下，如果我有类似 fb_exchange_token 的选项，可以将 60 天令牌交换为新的 60 天令牌，我可以编写一些东西，每天对 facebook 进行一次采样，以查看我的 60 天令牌离到期有多近以及何时到期一两天执行一个新的 fb_exchange_token 并保存新的 60 天令牌。

对不起，如果这是一个罗嗦的帖子。我试图将所有信息都放在那里，以便有人可以提供帮助而无需提出后续问题。

4

1 回答 1

1

据我了解，如果没有用户再次登录，我将无法获得新的短期令牌。

好吧，这就是删除 offline_access 的全部意义……</p>

假设我有一个 bash 脚本，该脚本每 90 天在 cron 中运行一次，以向公司的 facebook 页面发布消息，宣布季度报告可用。在新的、已弃用的 offline_access 世界中，我怎样才能使这个 cron 工作正常工作？

使用页面访问令牌而不是用户访问令牌 -页面访问令牌不会过期（只要您获得它们的用户没有更改他的密码或完全离开平台）。

如果我做了最骇人听闻的解决方案，并要求安装我们的应用程序的人在安装过程中包含他们的 fb 用户名和密码，那将如何工作。

这将明显违反 FB 平台政策。你甚至不应该考虑这样做。

理想情况下，如果我有类似 fb_exchange_token 的选项，可以将 60 天的代币换成新的 60 天的代币 […]

同样，如果 Facebook 希望这成为可能，他们一开始就不需要删除 offline_access。

于 2012-06-28T09:24:54.207 回答