4

oEmbed规范提到了 2 种查找 URL 的 oEmbed 内容的不同方法：

  1. 了解网站的 API 端点并通过 GET 参数传递您想要了解的 URL（如果它与它声明的 URL 模式匹配）。
  2. <link rel="alternate" type="application/json+oembed" ... />借助（或text/xml+oembed）HTML 标头发现 oEmbed 版本的 URL 。

第二种方式似乎更通用，因为您不必存储和维护提供者的完整列表。此外，提供者名单是集中式互联网的标志，其中只有少数参与者。这种方法很难扩展。

不过，对于可以解析其他人提供的资源的网站，我可以看到第一种方法的用途。例如，我可以提供来自 Foo 网站的 oEmbed 版本的视频页面。然而，出于几个原因，主要是与安全相关的，我不会相信有人说“我可以为你解析资源 X”，除非 X 的作者对此表示同意，这让我们回到方法 2。

所以我的问题是：我在这里错过了什么？第一种处理oEmbed的方法有什么用？例如，如果您有一种通用的方式来即时发现互联网上的几乎任何资源，为什么还要存储（并保持最新）端点和模式的完整列表（如 oohEmbed ）呢？

作为一个非常密切相关的问题，我认为可能会同时提出这个问题（如果我错了，请纠正我）：如果一个人没有为 oEmbed 内容提供中心端点，而是说，期待一个每个 URL 上的 '?version=oembed' 参数，返回 oEmbed 版本而不是标准版本？

4

3 回答 3

4

如果我没记错的话，支持这两种机制是一种妥协，我们认为这将有助于推动采用。说服大型 Web 属性添加单个端点比向每个响应正文添加标记（与大多数客户端无关）要容易得多。这是一个务实的选择。

从长远来看，我们计划利用 Eran Hammer-Lahav 围绕发现所做的一些工作，而不是重新发明它（再次糟糕）。不幸的是，他的想法仍然没有得到太多的关注，而且网络仍然缺乏一种好的、标准化的方式来做这种事情。

于 2011-11-03T00:31:35.463 回答
1

我希望在这里找到答案，但看起来其他人都和我们一样困惑。在我看来，使用选项 1 的优点是它只使用 1 个 json 请求，而不是一个可能很昂贵的 html 请求，然后是 json 请求。如果您无法匹配 oEmbed 提供程序的预烘焙列表中的模式，您始终可以使用选项 2 作为后备。

于 2011-09-28T04:04:05.423 回答
0

Oembed 发现是一个主要的安全问题。例如，WordPress 有一个受支持的 OEmbed 提供程序的白名单。

假设互联网上的每个随机 URL 都可以触发 OEmbed 代码。这意味着每个人都可以破解您的网站。

脚步：

  1. 创建一个新站点，添加一个 OEmbed 发现。
  2. 将 URL 发布到您站点上的表单中。现在您的站点代表我执行 OEmbed。

  3. 开发：

    • 通过拒绝服务 (DOS)：例如将 URL 重定向到 tarpit 或提供 1GB json 响应。
    • 通过跨站点脚本 (XSS)：将随机 HTML 注入其他人可以看到的页面。
    • 通过 XSS 窃取管理员的 session-cookie：现在攻击者可以登录到您的 CMS 上传文件，并利用更多。

这是最大的 XSS，几乎无法阻止它。唯一明智的做法是将适当的端点列入白名单。那就是明确列出了 oEmbed 端点。

如果你想要一些可扩展的东西，你可能会喜欢 www.noembed.com 和 www.embedly.com 他们为不做 Oembed 的各种站点提供 Oembed 支持。

于 2013-03-24T12:22:26.773 回答