0

每次阅读https://developers.facebook.com/roadmap/offline-access-removal/时，我都比以前更加困惑。我正在寻找对场景 3 和 4（服务器端应用程序和客户端应用程序）下某些项目的一些说明

对于服务器端应用程序，它声明“如果在该用户仍有有效的 60 天 access_token 时进行调用，则第二次调用返回的 access_token 可能相同或可能已更改，但在任何一种情况下都过期时间将是全新的 60 天。”

  • 这里所说的“呼召”是什么？
  • 是否与初始 OAuth 流程中发生的访问令牌的授权代码交换相同？
  • 还是客户端部分下描述的端点调用将令牌更新为 60 天？
  • 如果是前者，那么在尝试更新令牌时授权码来自哪里？
  • 它与原始回调中的授权代码相同还是我必须再次通过授权流程？

简而言之，服务器端应用程序能否不断更新 60 天令牌的生命周期？如果可以，那么如何？

关于客户端使用，该文档指出客户端必须进行端点调用（除其他外）传递应用程序的客户端 ID 和客户端密码。

  • 我对“客户端”的解释可能是错误的，但我考虑的是在 Web 浏览器中运行的基于 JavaScript 的客户端。
  • 如果这就是 Facebook 的想法，那么 JavaScript 代码真的应该知道客户端机密吗？（如果它被发送给客户，这将不是什么秘密。）

即便如此，它也表明 60 天的代币不能延长其寿命，并且必须首先获取一个新的 2 小时代币并用于获得 60 天的代币。这是文档的客户端部分，但此规则是否也适用于服务器端 60 天令牌？如果没有，那我再问一遍：如何在服务器端更新 60 天令牌的生命周期？

最后，一直萦绕在我脑海中的问题是：为什么 Facebook 采用了这种策略，而不是采用 OAuth 2 规范（Facebook 正在帮助定义的规范）中定义的刷新令牌？

编辑：再次阅读文件后的进一步想法/问题：

一开始它说“每次用户修改您的应用程序时都可以更新的长期过期时间”。我最初的假设是更新它的方法是在文档的后面调用端点。但是，除了端点在“客户端”标题下描述的事实之外，它还声明“请注意，端点只能用于扩展短期用户 access_tokens。如果您传递的 access_token 具有长时间的过期时间，端点将简单地将相同的 access_token 传回给您，而不会更改或延长过期时间。” （“长期存在”的错字来自 FB 自己的文档。）

好的，因此，如果该端点不能用于更新到期时间（并且我自己尝试使用该端点更新长期令牌的尝试证明了这一点），那么我如何每次都更新长期令牌的过期时间他们访问我的应用程序？

没有人了解这应该如何工作吗？

4

1 回答 1

0

在阅读了 Facebook 的文档（如第五次）并借助这个问题/答案之后，这是我的结论。

这里所说的“呼召”是什么？

它引用 OAuth 调用来获取访问令牌。

是否与初始 OAuth 流程中发生的访问令牌的授权代码交换相同？

是的，我相信就是这样的流动。

还是客户端部分下描述的端点调用将令牌更新为 60 天？

不，该端点仅对短期访问令牌有效。

它与原始回调中的授权代码相同还是我必须再次通过授权流程？

您必须再次完成授权流程。

每次他们访问我的应用程序时，如何更新长期令牌的到期时间？

无法使用客户端端点更新长期访问令牌。用户必须重新授权应用程序才能获得新的应用程序。根据 Facebook 文档：

如果调用（OAuth 授权调用）时该用户仍有一个有效的长寿命用户 access_token，则第二次调用返回的用户 access_token 可能相同或可能已更改，但在任何一种情况下，到期时间都将设置为较长的​​过期时间。

重新授权应用程序后，您将获得新的到期时间。Facebook 可能会返回一个新的长期访问令牌，因此您应该获取它并将该信息替换为您已经拥有的那个。

结论：似乎没有用户干预就无法更新长期访问令牌。要获得新的过期时间/访问令牌，他们必须重新授权您的应用。我的谦虚建议是，应该建议用户在到期日期前几天重新授权。此外，这个Facebook 操作方法可以派上用场检查过期的访问令牌。

于 2012-04-30T14:55:39.350 回答