Facebook客户端身份验证和offline_access弃用

时间:2012-04-21 13:02:11

标签: facebook-graph-api access-token facebook-access-token

在你开始对我大吼大叫之前,我知道很多用户已经要求这样的东西了,但是我读了所有这些用户并且找不到与我的具体案例相关的任何答复:我最终设法得到了一些工作但是它不是我认为我(以及其他开发者)正在寻找的东西。我想与大家分享一下我的经历,所以我会尝试描述我的场景以及我所采取的步骤,以便了解如何处理这个问题,所以请放纵我这篇长篇文章:I&# 39;我相信它会帮助处于同样情况的一些开发人员清除他们的想法,就像我希望它能给别人提供正确的信息来帮助我(和其他人)一起使用它。

我编写了一个使用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=token&display=wap
  3. 我得到了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 ...请求显然是成功的,但 NOT 延长了任何事情的生命周期。请求刚刚返回与之前相同的access_token,其expires_in参数只反映了流逝的时间(与之前相同,减去自我授权后经过的秒数)。基本上,这种方法只告诉我已经有多少access_token可以存在,而不刷新或改变任何东西,所以,尽管它引起了明显的安全问题,但它也没用。
    2. 然后我尝试了其他人的建议,即使用旧的REST API来完成这项工作,向以下地址发出GET请求:https://api.facebook.com/method/auth.extendSSOAccessToken?access_token=EXISTING_ACCESS_TOKEN这显然也失败了臭名昭着的"访问权限使用单点登录"无法获得令牌。错误。
    3. 在那些尝试失败之后,我开始考虑可能导致所有这些失败的原因。正如我所料,我的应用程序在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获得的。
      3. 所以,非常长话短说(我知道,为时已晚),贬低offline_access的截止日期是如此接近你可以感觉到它在你的脖子上呼吸,似乎没有任何效果。你对这一切有什么经验,如果你和我在同一条船上并且你设法让它运转起来,你是怎么做到的?

        感谢您的耐心等待。

0 个答案:

没有答案