现在，如果不推荐使用offline_access，我该如何处理服务器端身份验证？

Question

随着即将到期的访问令牌的终止，我希望有人可以帮助解决我这个相当独特的问题。

我已阅读有关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弃用，此访问令牌现在是一个短期令牌，显然可以通过转到

来交换为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天令牌。我发现获得一个新的短期令牌的唯一方法是让用户登录并生成它。那是我的问题。据我了解，如果没有用户再次登录，我就无法获得新的短期令牌。

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

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

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

理想情况下，如果我有类似fb_exchange_token选项的东西，可以为60天的新令牌交换60天令牌，我可以写一些每天一次取样facebook的内容，看看我的60天令牌到期有多近以及何时到期它会在一两天内执行一个新的fb_exchange_token并保存新的60天令牌。

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

Answer 1

  

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

嗯，这是删除offline_access ...

的整个点

  

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

使用页面访问令牌而非用户访问令牌 - 页面访问令牌不会过期（只要用户为您从没有更改密码或完全离开平台来获取它们。

  

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

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

  

理想情况下，如果我有类似fb_exchange_token选项的东西可以为60天的新令牌交换60天令牌[...]

同样，如果Facebook希望这样做，他们就不需要首先删除offline_access。