我仍然不清楚情况 - 2012 年 7 月 5 日之后，如果与访问 token 关联的用户从 Facebook 注销，桌面应用程序是否能够访问 Facebook 数据？ 这里谈论的是完全删除离线访问还是只是限制离线访问 60 天？
文档 - https://developers.facebook.com/roadmap/offline-access-removal/没有给出明确的答案(恕我直言)。引用:“启用迁移设置后，桌面应用程序将自动返回过期时间较长的用户 access_token。但是，如果用户不再次登录您的应用程序，就无法获得长期存在的用户 access_token。”
截至 4 月 30 日，我可以为桌面应用程序请求具有“offline_access”权限的访问 token (使用 URL:https://graph.facebook.com/oauth/authorize?client_id=APPLICATION_ID&redirect_uri=http://www.facebook.com/connect/login_success.html&scope=manage_pages,read_stream,publish_stream,offline_access )。一切都很好。即使用户退出。尽管为应用程序启用了“删除离线访问权限”。
我们将非常感谢您的回答。
最佳答案
刚刚完成了一个补丁来适应这些更改。至少根据我的经验，我们在一个 Web 应用程序中工作，其中更新访问 token 就像将所有内容更改为 Javascript SDK 并依赖于浏览器的登录状态一样简单。这似乎是一种比在每个操作中交叉检查服务器端保存的长期过期访问 token 以查看它是否仍然有效更合乎逻辑的方法。
本质上，桌面实现将会发生的情况是，默认情况下访问 token 的生命周期将更长，但仍然需要在六十天期限结束时续订。您的应用程序中应该有逻辑，在对其采取操作之前，先使用 facebook 检查访问 token 的有效性(或者只是尝试并提示失败)，然后提示用户登录并在 access_token 已过期时重新验证。只要此逻辑到位，过期的访问 token 就会触发重新验证。
如果您的应用收到短期访问 token ...
If you would like to refresh a still valid long-lived access_token, you will have to get a new short-lived user access_token first and then call the same endpoint below. The returned access_token will have a fresh long-lived expiration time, however, the access_token itself may or may not be the same as the previously granted long-lived access_token.
短期访问 token (即仅持续一个 session 直至注销的类型)需要使用该文章中记录的端点转换为 60 天的长期过期访问 token 。配置为新设置的桌面应用程序将默认收到这些类型，但仍需要在 60 天后通过新登录重新生成这些类型。
我同意这实现起来要笨拙得多，尤其是对于桌面应用程序来说，但从 Facebook 的角度来看，它肯定要安全得多。如果您开始将访问 token 视为暂时的而不是永久的访问凭证，并开始更改您的逻辑以通过curl或其他一些http post机制检查有效性，而不是引用您的数据库，那么您将更轻松地使用调整。不要让您的架构假设保存的访问 token 的存在可以保证访问，并确保在 Facebook 端点上交叉检查它们，并在必要时提示重新登录。
关于facebook-graph-api - 离线访问。 7 月 5 日之后，将桌面应用程序。如果与访问 token 关联的用户从 FB 注销，是否能够访问 FB 数据？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10389270/