3

在你开始对我大喊大叫之前，我知道很多用户已经要求过这样的事情，但我阅读了所有这些，但找不到与我的具体案例相关的任何回复：我最终设法让一些工作正常，但这不是我想的那样我（和其他开发人员）正在寻找。我想与大家分享我对此的经验，所以我将尝试描述我的场景以及我遵循的步骤来研究如何解决这个问题，所以请放纵我这篇长篇文章：我确定它也将帮助一些与我处于相同情况的开发人员清除他们的想法，就像我希望它会给其他人提供正确的信息来帮助我（和其他人）一样。

我编写了一个使用 Facebook API 的原生 Android 应用程序。我不使用 Facebook SDK，因为我不想依赖安装在设备上的官方应用程序（事实上，我的应用程序在一定程度上是该应用程序的替代品，所以这样做很愚蠢无论如何都需要首先安装它），但我宁愿直接通过 HTTP 发出 Graph API 调用并自己处理响应。所以如果这是你想给我的答案，请不要因为我不会走那条路。

因此，我使用客户端身份验证来授权我的应用程序，在 WebView 中显示 URL 并在最后获取 access_token。我在其他权限中请求了offline_access。

由于offline_access 将在5 月份被弃用，我开始研究如何获得长期存在的令牌，因此阅读了我能找到的几乎所有与此相关的内容，当然包括官方指南。长话短说，没有什么对我有用，而且我仍然坚持使用非常短暂的 access_tokens，我无能为力。

这就是我开始做的事情：

  1. 在设置中弃用了我的应用程序的offline_access（不是应用程序，因为它现在被许多用户使用，但另一个基本相同，我仅用于测试目的，所以这是同一件事）。
  2. 使用客户端身份验证授权用户：https ://www.facebook.com/dialog/oauth?client_id=MY_APP_ID&redirect_uri=http://my.domain.com/yeah.htmlscope=publish_stream,read_stream,user_photos,friends_photos,offline_access&response_type =令牌&显示=wap

我得到了我的 access_token，但我立即注意到它根本不存在，恰恰相反：expires_in 设置为 6800 秒（不到两个小时）。所以我所做的第一个假设（默认情况下 access_tokens 会更长寿）已经是错误的。

我当时研究了如何延长这个 access_token 的生命周期，并尝试了几乎所有的替代方案。不用说，每次尝试都失败了。这就是我尝试过的，确切地说：

  1. 首先，我当然尝试了“官方”的方法，即通过新端点扩展令牌。现在跳过关于为这样的操作请求客户端密码是多么愚蠢的咆哮（正如许多人已经指出的那样，这样的秘密需要嵌入到 Android 应用程序中，就我们开发人员而言，这是一场安全噩梦。担心，并且代表用户移动这个位服务器端以延长令牌寿命对于他们所关心的事情来说是一场噩梦，因为他们需要相信我会弄乱他们的 access_token），我尝试发出 GET 请求该地址使用正确的参数：https ://graph.facebook.com/oauth/access_token?client_id=APP_ID&client_secret=APP_SECRET&grant_type=fb_exchange_token&fb_exchange_token=EXISTING_ACCESS_TOKEN...请求显然是成功的，但它并没有延长任何东西的生命周期。该请求刚刚返回与以前相同的 access_token，并带有一个 expires_in 参数，该参数仅反映了流逝的时间（与以前相同，减去自我授权以来经过的秒数）。基本上，该方法只告诉我已经可用的 access_token 可以存活多少，而无需刷新或更改任何内容，因此，尽管它引发了明显的安全问题，但它也毫无用处。
  2. 然后我尝试了其他人的建议，即使用旧的 REST API 来完成这项工作，向以下地址发出 GET 请求：https ://api.facebook.com/method/auth.extendSSOAccessToken?access_token=EXISTING_ACCESS_TOKEN这显然也因臭名昭著的“未使用单点登录获得访问令牌”错误而失败。

在那些失败的尝试之后，我开始思考可能导致所有这些失败的原因。正如我所料，我的应用程序在 Android 设备上运行，但直接向 API 发出 HTTP 请求，我想这可能是问题的根源。

  1. 在我的开发者应用页面的高级部分，我的应用被配置为“Web”而不是“Native/Desktop”。也就是说，将其更改为“Native/Desktop”只会在第一次注销时（大约 24 小时而不是 1-2 小时）给我一个寿命更长的 access_token，而已经描述的延长其寿命的尝试和以前一样失败了。
  2. 官方指南有一个有趣且令人毛骨悚然的段落：“桌面应用程序将无法延长现有 access_token 的寿命，并且一旦令牌过期，用户必须登录到 facebook”。虽然这似乎被许多人忽视了，但我开始认为这可能是我的问题的原因，所以我尝试了另一种方法，即我尝试了服务器端身份验证而不是客户端身份验证：再次，这个需要 client_secret 所以对于 Android 应用程序来说是一个愚蠢的解决方案，但我还是想尝试一下。所以，我首先得到了代码，然后是 access_token（如http://developers.facebook.com/docs/authentication/server-side/中所述）。这导致 access_token 的寿命更长（5183882 秒，即大约 59 天），但话又说回来，两种已知的扩展它的方法（即使在这种情况下并不真正需要）导致同样的事情：前者不刷新任何东西，后者抱怨它不是通过 SSO 获得的。

所以，长话短说（我知道，为时已晚），弃用offline_access 的最后期限是如此之近，以至于你可以感觉到它在你的脖子上呼吸，似乎没有任何效果。你对这一切有什么经验，如果你和我在同一条船上并且你设法让它工作，你是怎么做到的？

谢谢你的耐心。

4

0 回答 0