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