很少有同名的问题，但没有一个是想问我在想什么。所以我们只用 app id 初始化 FB js sdk。通过查看他们的 facebook 初始化源代码很容易知道其他网站的应用程序 ID。有人可能认为黑客可能会尝试使用其他应用程序 ID 初始化 FB JS SDK 并尝试获取他们的用户访问令牌。但是facebook不允许这样的东西。您必须从您在 Facebook 开发人员应用程序页面的站点 url 属性中指定的同一域加载 js sdk。所以问题是他们怎么知道 jsonp 不管调用来自正确的客户端？在客户端检查是不安全的，因为人们可以根据需要复制和修改 javascript。所以它必须是服务器端检查。我只能想到“推荐人检查”
问问题
1611 次
1 回答
1
好吧，我不确定，所以这只是猜测..
首先，在发出 http 请求时，会添加HTTP 引用标头，因此当您加载 sdk 时，发出请求的 url 将被添加为引用者。Facebook 可以检查其请求的来源服务器，并将其与他们的应用程序设置进行比较。
当然可以在发出请求时修改此标头，这就是为什么如果您在错误的域中仅通过加载应用程序的 sdk 就不会收到任何错误的原因。该错误只会在您尝试与 sdk 交互时发生，例如尝试执行FB.login方法将打开身份验证对话框弹出窗口，其中将显示以下错误消息：
发生错误。请稍后再试。
如果您检查此身份验证对话框（由 sdk 构建）的 url，您会注意到这两个查询字符串参数：
- 域=THE_DOMAIN_OF_THE_PAGE
- redirect_uri=FACEBOOK_URL 将包含来源、域和关系=opener
（可能）发生的情况是facebook根据应用程序设置检查域，如果没问题，它会向用户显示身份验证对话框，当他完成该过程时，他会被重定向到redirect_uri。
由于redirect_uri 在弹出窗口中打开，它只能与它的打开器通信，如果它们都在同一个域中，一个facebook 域，除了从facebook 提供的页面之外，没有人可以在他的页面上拥有它。
当 sdk 加载时，它会在fb-root容器中添加一个 iframe，该容器会加载一个从与 redirect_uri 相同的域加载的 facebook js，因为弹出窗口可以与 iframe 通信并通过身份验证通知它回复。
iframe 收到响应后，弹窗关闭，iframe 将响应通知主页中加载的 sdk。我不确定他们使用哪种技术进行通信，但您可以通过谷歌搜索“跨域 iframe 通信”轻松找到更多信息。
这就是我的看法，但我不能确定。如果您想真正了解发生了什么，您可以查看js sdk @ github的代码。
于 2012-04-20T00:56:45.443 回答