offline_access弃用和方案3和4

时间:2012-04-24 21:15:50

标签: oauth facebook-oauth

每当我阅读https://developers.facebook.com/roadmap/offline-access-removal/时,我都会比以前更加困惑。我正在寻找对方案3和4(服务器端应用程序和客户端应用程序)下的一些项目的一些澄清

对于服务器端应用程序,它指出“如果在该用户仍有有效的60天access_token时进行了呼叫,则来自此第二次呼叫的返回的access_token可能相同或可能已更改,但是如果到期时间是新的60天。“

  • 这里提到的“电话”是什么?
  • 在初始OAuth流程中发生的访问令牌的授权代码是否相同?
  • 或者是客户端部分描述的端点调用是否将令牌刷新为60天?
  • 如果是前者,那么授权代码在尝试续订令牌时会从哪里来?
  • 它与原始回调中的授权码相同,还是必须再次通过授权流程?

简而言之,服务器端应用程序是否可以保持60天令牌的寿命,如果是,那么如何?

关于客户端使用,该文档指示客户端必须使该端点调用传递(除其他外)应用程序的客户端ID和客户端密钥。

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

即便如此,它表明60天的代币不能延长寿命,必须首先获得新的2小时代币并用于获得60天的代币。这是在文档的客户端部分,但此规则是否也适用于服务器端60天令牌?如果没有,那么我再问:我如何在服务器端刷新60天令牌的生命?

最后,这个问题在我脑海中浮现了一段时间:为什么Facebook采用了这种策略而没有采用OAuth 2规范中定义的刷新令牌(Facebook正在帮助定义的规范)??? / p>

编辑:重新阅读文档后的进一步想法/问题:

一开始它表示“每次用户撤销您的应用时都可以续订的长期过期时间”。我最初的假设是更新它的方法是在文档的后面调用端点。但是,除了在“客户端”标题下描述端点这一事实外,它还指出“请注意,端点只能用于扩展短期用户access_tokens。如果你传递的access_token有一个在长期的过期时间内,端点只会将相同的access_token传回给您,而不会改变或延长过期时间。“ (关于“长篇大论”的错字来自FB自己的文档。)

好吧,如果该端点不能用于更新到期时间(并且我自己尝试使用该端点续订长期令牌证明了这一点),那么如何更新到期时间更长每次他们访问我的应用程序时都会使用令牌?

没有人知道这应该如何运作吗?

1 个答案:

答案 0 :(得分:0)

在阅读了Facebook的文档(比如第5次)并在this question/answer的帮助下,这是我的结论。

  

这里提到的“电话”是什么?

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

  

是否与访问令牌的授权代码交换相同   这是在最初的OAuth流程中发生的吗?

是的,我相信这就是流动。

  

或者它是客户端部分下描述的端点调用   把令牌清新到60天?

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

  

它是来自原始回调的相同授权码还是我   必须再次通过授权流程吗?

您需要再次完成授权流程。

  

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

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

  

如果在仍有效的长期用户的情况下进行了呼叫(OAuth授权呼叫)   对于该用户的access_token,返回的用户access_token来自此   第二次通话可能相同或可能已经改变,但在任何一种情况下   到期时间将设置为较长的​​到期时间。

一旦申请被重新授权,您将获得新的到期时间。 Facebook可能会返回一个新的长期访问令牌,所以你应该抓住它并替换你已经拥有的那个信息。

结论: 似乎没有用户干预就无法续订长期存取令牌。要获得新的到期时间/访问令牌,他们必须重新授权您的应用。我的拙见是建议用户在到期日前几天重新授权。 此外,这个Facebook how-to可以用来检查过期的访问令牌。