CORS相对于跨域消息传递的优势

Benefit of CORS over cross-domain messaging

本文关键字：消息传递 相对于 CORS      更新时间：2023-09-26

CORS和跨域消息传递在我看来是一样的:它们允许跨域通信。

是否有理由使用其中一个而不是另一个?

CORS用于ajax请求或flash请求，而flash通常不允许。例如，如果域x没有跨域策略，并且您通过flash从那里检索mp3文件进行播放，那么flash将不允许您读取mp3文件的id3标记。对于ajax，如果目标服务器没有允许您的域发出请求的跨域策略，则无法发出请求。

跨域消息传递允许您与来自不同来源的文档中的iframe进行通信。例如，如果你有youtube视频iframe，你可以传递一个消息给该iframe来改变音量。通常情况下，没有通信是不可能的，因为iframe有一个不同的起源，所以你不能用编程对youtube iframe做任何事情。

使用其中一个或另一个的原因现在应该很清楚了。CORS允许你从另一个源请求数据，而主窗口和iframe之间的消息传递是当你想要与iframe内部的应用程序通信时使用的，但不是在同一个源。

一个实际的例子:

1。你有一个iframe，里面有一个youtube播放器

2。你请求一些视频从youtube数据api (CORS，可以是JSONP, XHR或其他)播放。

3。现在，您可以向iframe传递一个跨域消息，开始播放您在步骤#2中请求的任何视频

首先，您应该知道CORS支持以下浏览器:Internet Explorer 8+， Firefox 3.5+， Safari 4+和Chrome。请注意，IE7和旧版本的Firefox和Safari根本不支持它。但是IE8有一些限制——它不支持凭据和发送到服务器的"预飞行"请求。此外，您的服务器应该为CORS请求做好准备，也就是说，应该在服务器上执行一些额外的工作。

使用JSONP或iFrames的跨域消息传递在浏览器支持方面更加通用，有时甚至不需要额外的服务器端工作。

我相信问题的实质是"对于跨域XHR, CORS和基于iframe+ postmessage的方法的相对优缺点是什么?"

解释它们的用途并不能真正帮助回答这个问题。

在这里，我试图从一个想要提供"服务"的服务提供者的角度来回答这个问题。(数据，行为)到特定的已知页面/域，并需要这些域能够"调用";。

歌珥

  • 优点
    • 当它工作时很容易理解/超级容易在客户端(不需要任何复杂的逻辑，一个简单的XmlHttpRequest/fetch调用将做的技巧)
  • 缺点
    • 性能:每个新URL(以及在CORS授权过期后先前访问的URL)的前期往返开销
    • 可能复杂/经常被误解的服务器端实现(指定何时应该允许CORS，处理特定动词等)
    • 跨浏览器的支持覆盖率略低(比postMessage): https://caniuse.com/#feat=cors vs https://caniuse.com/#feat=x-doc-messaging

iframe + postMessage

  • 优点
    • SameSite cookie处理不是问题(跨越域边界的是postMessage调用，而不是XHR调用)
    • 简单的服务器端实现(只托管一个"页面")包含你的JS代码和跨域消息传递规则;大部分复杂性最终在前端JS中结束)
  • 缺点
    • 客户端更多的工作;如果您提供一个服务，而不是提供一个简单的端点，您需要提供一个"sdk"，一个在目标页面中执行的脚本。
    • 潜在的复杂/经常被误解的客户端实现(指定应该允许哪些来源发送给您等)
    • 处理大消息时可能比大XHR有效载荷到达时影响更大??https://dassur.ma/things/is-postmessage-slow/
    • 如果你设置了&;x - frame - options &;为了帮助保护您的(提供服务的)站点-您需要为消息传递iframe主机"页面"添加一个豁免。

(请调整/正确/添加!)

相关文章：