java - 既然offline_access 已被弃用，我该如何处理服务器端身份验证？

Question

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

我已阅读有关 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

从历史上看，我的应用程序会将生成的访问 token (永不过期)存储在数据库中。现在，随着offline_access的弃用，这个访问 token 现在是一个短期 token ，显然可以通过转至

交换为 60 天 token

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 并存储返回的长期访问 token 。到目前为止，一切都很好。问题就在这里......

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

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

假设我有一个 bash 脚本，每 90 天在 cron 中运行一次，向公司的 Facebook 页面发布一条消息，宣布季度报告可用。在新的、已弃用的offline_access 世界中，我怎样才能让这个 cron 作业发挥作用？我存储的唯一客户特定数据是 60 天的访问 token ，并且 bash 脚本没有用户界面。

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

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

抱歉，如果这是一个冗长的帖子。我试图获取所有信息，以便有人可以提供帮助，而不必提出后续问题。

Answer 1

As I understand it I can't get the new short-lived token without having a user log in again.

嗯，这就是删除offline_access的全部点......

Assume I have a bash script that runs in cron every 90 days to post a message to a company's facebook page announcing that the quarterly reports are available. In the new, deprecated offline_access world how could I make this cron job work?

使用页面访问 token 而不是用户访问 token – 页面访问 token 不会过期(只要您的用户从不更改密码或完全离开平台获得它们)。

If I did the hackiest solution and required the person who installed our application to include their fb username and password as part of the installation how would that even work.

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

Ideally if I had something like fb_exchange_token option that could exchange a 60-day token for a new 60-day token […]

再说一次，如果 Facebook 希望实现这一点，他们就不需要首先删除offline_access。