标签: facebook-access-token

我正在开发一个将facebook页面作为其数据源之一的项目.它定期从中导入一些数据,不涉及GUI.然后我们使用Web应用程序显示我们已有的数据.

并非所有信息都是公开的.这意味着我必须访问一次数据然后保留它.但是,我不知道这个过程,我还没有找到一个很好的教程.我想我需要一个access_token,如何从用户那里逐步获得它？用户是Facebook页面的管理员,他是否必须在页面中添加一些我们的FB应用程序？

编辑:谢谢@phwd的提示.我做了一个教程,如何获得永久页面访问令牌,即使offline_access不再存在.

编辑:我刚刚发现它的回答:持久的FB访问令牌服务器拉FB页面信息

我知道有很多关于Facebook访问令及其引起的悲痛的问题,但尽管进行了大量实验并阅读了许多令人沮丧的模糊博客文章(FB等),我仍然在努力为我的需求做出明确的回答.到目前为止,让我简洁地分解我的过程:

• 我正在创建一个站点,服务器端,需要从单个Facebook页面提取帖子/状态
• 我是Facebook页面的管理员
• 我创建了一个Facebook应用程序
• 使用Facebook Graph API Explorer,我生成了一个短链密钥,连接到我的应用程序和我的帐户,授予我的帐户权限以查看我的网页的访问令牌
• 我已经将我短暂的键从一个长寿命密钥(60天)ALA方案4 本

而这就是我被困的地方.我的60天密钥适用于我的服务器从页面中提取所需的信息,但据我所知,没有办法以编程方式扩展该60天密钥.我也不知道如何生成新的短期密钥,而无需手动访问Facebook Graph API Explorer并创建一个.

由于我的服务器向Facebook API发出请求而不是基于用户的系统(我可以轻松地请求用户再次授权Facebook应用程序),这会创建一个非常笨重的系统.由于Facebook已offline_access被弃用,是否真的没有永久的方法让我的服务器从我自己的页面提取信息？我是否真的需要手动创建一个新密钥并每60天手动更新一次我的服务器？

还是有什么我想念的？

更新:

之前在此处找到的分步指南已经迁移到自己的答案中.

前言

我正在开发几个Web服务和一些客户端(Web应用程序,移动设备等),它们将通过HTTP与所述服务进行交互.我目前的工作项目是为产品设计身份验证和授权解决方案.我已决定利用外部身份提供商(如Facebook,Google,Microsoft,Twitter等)进行身份验证.

我正试图解决这个问题,"当我的服务器发出请求时,我怎么知道用户是谁以及我怎么能确定？".下面还有更多问题......

要求

1. 依靠外部身份来表明我正在与谁打交道('userId'基本上就是我所关心的).

2. 系统应使用基于令牌的身份验证(而不是cookie或基本身份验证).

   我相信这是扩展多个客户端和服务器同时提供松散耦合的正确选择.

工作流程

根据我对基于令牌的身份验证的阅读和理解,以下是我想象的工作流程.现在让我们在Facebook浏览器上关注Facebook.我的假设是其他外部身份提供者应该具有类似的能力,尽管我还没有确认.

请注意,截至撰写时,我的基础是Facebook登录版2.2

1. 客户:使用JavaScript SDK启动登录Facebook
2. Facebook:用户验证和批准应用权限(例如访问用户的公开个人资料)
3. Facebook:向客户发送响应,其中包含用户的访问令牌,ID和签名请求
4. 客户端:在浏览器会话中存储用户访问令牌(方便地由SDK处理)
5. 客户端:通过在授权标头中发送用户的访问令牌+用户的ID(可能在自定义标头中),向我的Web服务请求安全资源
6. 服务器:从请求标头读取用户访问令牌,并通过向Facebook提供的debug_token图形API发送请求来启动验证
7. Facebook:使用用户访问令牌信息(包含appId和userId)回复服务器
8. 服务器:通过将appId与预期(自身已知)和userId与客户端请求上发送的内容进行比较,完成对令牌的验证
9. 服务器:使用请求的资源响应客户端(假设快乐的授权路径)

我想象对于后续的服务器请求会重复步骤5-9(当用户的访问令牌有效时 - 未过期,从FB端撤销,应用权限更改等)

这是一个帮助您完成这些步骤的图表.请理解这个系统不是单页面应用程序(SPA).提到的Web服务是基本上为客户端提供JSON数据的API端点; 它们不提供HTML/JS/CSS(Web客户端服务器除外).

问题

1. 首先,根据我的前言和要求,所描述的方法是否有任何明显的差距/陷阱？

2. 是否正在向Facebook执行出站请求,以根据所需/推荐的客户端请求验证访问令牌(上面的步骤6-8)？

   我至少知道,我必须验证来自客户端请求的访问令牌.但是,我不知道在第一次验证后进行后续验证的推荐方法.如果有典型的模式,我很想听听它们.据我所知,根据我的要求,他们可能依赖于应用程序; 但是,我只是不知道该寻找什么.一旦我有了基本想法,我就会进行尽职调查.

   例如,可能的想法:

   • 在第一次验证完成后散列访问令牌+ userId对,并将其存储在分布式缓存中(可由所有Web服务器访问),其到期时间等于访问令牌.根据客户端的后续请求,对访问令牌+ userId对进行散列并检查其是否存在于缓存中.如果存在,则请求被授权.否则,请访问Facebook图形API以确认访问令牌.我假设如果我使用HTTPS(我会这样),这个策略可能是可行的.但是,性能如何比较？

   • 此StackOverflow问题中接受的答案建议在Facebook用户令牌的第一次验证完成后创建自定义访问令牌.然后,自定义令牌将被发送到客户端以用于后续请求.不过,我想知道这是否比上述解决方案更复杂.这需要实现我自己的身份提供者(我想避免的事情,因为我想首先使用外部身份提供者......).这个建议有什么好处吗？

3. 是signedRequest字段存在于在上述(步骤提到#3的响应此处),相当于签名的请求参数这里在"游戏画布登录"流？

   它们似乎被暗示为等同,因为前者在文档中与后者相关联.但是,我很惊讶在Web文档的"手动构建登录流程" 页面中没有提到游戏页面上提到的验证策略.

4. 如果#3的答案为"是",那么解码签名的相同身份确认策略是否可以与服务器端预期使用的策略进行比较？

   

   我不知道是否这可以利用,而不是把所述debug_token图形API的出站呼叫(步骤#6的上方),以确认访问令牌的建议这里:

   

   当然,为了在服务器端进行比较,需要将签名的请求部分与请求一起发送到服务器(上面的步骤#5).除了在不牺牲安全性的情况下的可行性之外,我想知道性能与进行出站呼叫相比如何.

5. 虽然我正处于这种状态,但在什么情况/出于何种目的,您是否会将用户的访问令牌持久存储到数据库中？我没有看到我需要这样做的场景,但是,我可能会忽视某些事情.我很好奇是一些常见的场景可能会引发一些想法.

谢谢!

我正在尝试从用户获取访问令牌

string response_script = "<script>top.location.href='https://www.facebook.com/v2.4/dialog/oauth?response_type=token&client_id=[APPLICATION ID]&redirect_uri=https://www.facebook.com/[APPLICATION URL]/?sk=app_[PAGE ID]&scope='; </script>";

但我收到一个错误:

无法加载网址:此网址的域名未包含在应用的域中.要加载此网址,请将应用的所有域和子域添加到应用设置中的应用域名字段中.

该代码运作良好.所以我认为需要添加我的网址

有效的OAuth重定向URI

但它不再存在于高级部分中.facebook改变了它的设计,现在它看起来像这样.这是太大的图像,因为我在stackoverflow之外

我能做什么？

在每次调用我的REST API时,我都要求客户端传递用户的facebook访问令牌,该令牌对用户进行身份验证.传递此令牌的最佳做法是什么？

1. 也许作为HTTP问号背后的参数

   GET /api/users/123/profile?access_token=pq8pgHWX95bLZCML
   

   Run Code Online (Sandbox Code Playgroud)

2. 或者以某种方式在请求的标题中,类似于HTTP基本认证

3. 也许是第三种选择？(我已经排除了在JSON中传递它,因为我希望令牌也在GET调用中传递,所以JSON不适合我认为)

我正在使用Facebook SDK开发一个ios应用程序来登录.我LogInViewController在故事板中设置了一个初始视图控制器,用户使用FB帐户登录.

我有另一个ViewController,一旦用户登录就可以正确加载.

在我正在检查的AppDelegate文件中currentAccessToken,如果它不是nil,我将直接加载第二个ViewController,因为用户已经登录.

但是,currentAccessToken如果我退出应用程序并重新启动它,则总是为零.它只有在我按下主页按钮并重新打开应用程序时它才有效,因为它仍然在后台运行.

以下是代码中的详细信息:

AppDelegate.swift

func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject: AnyObject]?) -> Bool {
    self.customNavigationBar()
    if (!isIcloudAvailable()) {
        self.displayAlertWithTitle("iCloud", message: "iCloud is not available." +
           " Please sign into your iCloud account and restart this app")
        return true
    }

    if (FBSDKAccessToken.currentAccessToken() != nil) {
        self.instantiateViewController("MapViewController", storyboardIdentifier: "Main")
    }

    return FBSDKApplicationDelegate.sharedInstance().application(application, didFinishLaunchingWithOptions: launchOptions)
}

func application(application: UIApplication, openURL url: NSURL, sourceApplication: String?, annotation: AnyObject) -> Bool {
    return FBSDKApplicationDelegate.sharedInstance().application(
            application,
            openURL: url, …

我正在REST使用api NodeJS.对于身份验证我决定使用Passport.我想要真正的RESTful api.所以这意味着我必须使用令牌而不是会话.

我想让用户使用用户名和密码登录,或者使用Facebook,Google和Twitter等社交网络.

我创建自己的OAuth2.0服务器来发布Access和Refresh tokens使用oauth2orize模块.所以现在我可以注册新用户,然后发出令牌.我按照本教程:

http://aleksandrov.ws/2013/09/12/restful-api-with-nodejs-plus-mongodb/

验证用户的路由:

// api ------------------------------------------------------------------------------------
    app.get('/api/userInfo',
        passport.authenticate('bearer', { session: false }),
        function(req, res) {
            // req.authInfo is set using the `info` argument supplied by
            // `BearerStrategy`.  It is typically used to indicate scope of the token,
            // and used in access control checks.  For illustrative purposes, this
            // example simply returns the scope in the response.
            res.json({ user_id: req.user.userId, name: req.user.username, …

在Facebook应用程序设置中☞高级☞身份验证我可以选择"Web"或"Native/Desktop"作为应用程序类型.信息泡泡说:

如果您是原生iOS或Android应用程序,设备或桌面应用程序,则仅选择Native/Desktop

实际上我不是那些,但我的应用程序是原生iOS应用程序以及Facebook页面选项卡.
问题:我应该选择哪种应用类型？

我做了一些研究,并在Facebook Android教程中找到了以下内容(在疑难解答下):

• 应用类型Web vs Native/Desktop.有关系吗？:不,没关系.但是,建议您为应用程序使用"Native/Desktop"类型.

这意味着什么并不重要？这对我来说没有意义.那我为什么要选择呢？

我做了所以一些更多的研究,发现这种说法通过@Igy(Facebook的开发支持工程师):

如果应用程序的类型设置为"Native/Desktop",则假定您使用二进制文件分发了应用程序的密钥,因此应用程序访问令牌不受信任(并且PHP SDK中的"getAccessToken"仅在真实用户登录时才起作用在,它不能回退到app令牌)

最后我在Facebook文档中找到了这个:

注意:配置为Native/Desktop应用程序的应用程序将无法进行需要应用程序的API调用access_token.

我确实需要从我的页面选项卡应用程序进行需要访问令牌的API调用,因此我的结论是选择"Web"作为应用程序类型,尽管我使用与页面选项卡相同的应用程序ID的本机iOS应用程序应用程序.但是iOS应用程序会有任何缺点吗？

我的客户公司为数千家小企业管理Facebook页面.我们构建了一个Facebook应用程序,供我们的客户简化流程,并允许他们一次快速地对多个/所有页面进行更改.

出于任何商业原因,我们的客户公司只为其中一个员工添加了管理员(以及小企业主)的每个页面.此用户帐户已添加我们的应用程序,我们正在抓取页面令牌并使用这些页面令牌来管理页面(更改联系信息,添加选项卡,获取墙上帖子).我们遇到了一些非常苛刻的api请求限制.现在我们每分钟只能添加3个新的Facebook页面(我认为这可能需要6-10次api调用才能完成所有操作).

我已经看到人们估计一个访问令牌允许大约600个请求/ 600秒,但我认为,由于我们使用页面令牌完成了大部分工作,因此我们的操作不会计入单个api限制.

有没有人知道api限制是否基于个人令牌,即使它们在技术上属于同一个用户？考虑到我无法真正为这些页面添加更多管理员,有什么方法可以绕过这个限制吗？

我刚开始将facebook整合到我正在处理的网站中,并按照以下说明尝试获取长期访问令牌:https://developers.facebook.com/docs/facebook-login/access-tokens/ 即使在这里使用Graph API资源管理器:https://developers.facebook.com/tools/explorer/ 我输入以下内容并使用我的AppID和AppSecret以及当我按下Get Access Token时得到的当前令牌填充它...

GET/oauth/access_token？
grant_type = fb_exchange_token&
client_id = {app-id}&client_secret = {app-secret}&fb_exchange_token = {short-lived-token}

我得到了回报

{"错误":"无效回复"}

有人可以详细说明我可能做错了什么,或者更详细的步骤,以便您获得这个长期令牌.

我试图关注这个帖子Facebook页面访问令牌中发生的事情- 这些过期了吗？没有更多的成功.任何帮助将不胜感激.

谢谢你的时间和帮助.干杯,

-Ryan