没有几个同名的问题,但他们都不打算问我心中有什么。因此,我们只使用app id初始化FB。通过查看其他网站的facebook初始化源代码,就可以很容易地知道其他网站的应用程序id。有人可能会认为,黑客可能会尝试用其他人的应用程序id初始化FB,并尝试获取用户访问令牌。但facebook不允许这样的事情发生。您必须从Facebook Developer Apps页面中的site属性中指定的相同域加载js。因此,问题是,他们如何知道jsonp --无论什么调用--来自正确的客户端?这种签入客户端是不安全的,因为人们可以根据自己的意愿复制和修改javascript。所以必须是服务器端的检查。我只能想到“推荐人检查”,但我觉得这不可能是一个安全的方法。
发布于 2012-04-20 00:56:45
我不确定所以这只是猜测..。
首先,在发出http请求时,会添加HTTP引用标头,因此在加载sdk时,您从其中发出请求的url将作为引用添加。Facebook可以检查他们的服务器,这是来自哪里的请求,并比较了他们的应用程序设置。
当然,在发出请求时可以修改这个标头,这就是为什么如果您在错误的域中加载应用程序的sdk,就不会得到任何错误。只有在尝试与sdk交互时才会发生错误,例如,尝试执行FB.login方法将打开auth对话框弹出,该对话框将显示以下错误消息:
发生错误。请稍后再试。
如果您检查这个auth对话框( sdk构造的)的url,您会注意到这两个查询字符串参数:
(可能)会发生的是,facebook根据应用程序设置检查域名,如果可以的话,当用户完成重定向到redirect_uri的过程时,它会向用户显示auth对话框。
由于redirect_uri在弹出窗口中打开,所以只有当它们都位于同一个域中时,才能与其打开器进行通信,这是一个facebook域,除了facebook提供的页面之外,没有人可以在他的页面上使用该域。
当sdk加载时,它会向from容器中添加一个iframe,该容器将从与redirect_uri相同的域加载facebook js,因为弹出窗口可以与iframe通信,并使用auth响应通知它。
在iframe获得响应后,弹出窗口关闭,iframe在响应的主页中通知加载的sdk。我不知道他们使用了哪种技术来进行交流,但是通过谷歌搜索“跨域iframe通讯”,你可以很容易地找到更多的相关信息。
我就是这么看的,但我不确定。如果您想真正知道发生了什么,可以检查js sdk @ github的代码。
https://stackoverflow.com/questions/10234906
复制相似问题