oEmbed API端点和URL方案与链接标记的重点是什么？

Question

oEmbed规范提到了两种不同的方法来查找网址的oEmbed内容：

1. 了解网站的API端点，并通过GET参数传递您想要了解的网址，如果它与其声明的网址格式相符。
2. 感谢<link rel="alternate" type="application/json+oembed" ... />（或text/xml+oembed）HTML标题，发现了oEmbed版本的网址。

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

但是，对于可以解析其他人提供的资源的网站，我可以看到第一种方法的用途。例如，我可以从网站Foo提供oEmbed版本的视频页面。但是，由于多种原因，主要是与安全相关的，我不相信有人会说“我可以为你解析资源X”，除非X的作者对此有所了解，这使我们回到接近2。

所以我的问题是：我在这里想念的是什么？第一种处理oEmbed的方法有什么用？例如，如果您有一种通用的方式即时发现它以及几乎任何互联网上的资源，为什么要存储（并保持最新）端点和模式的整个列表like oohEmbed does？ / p>

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

步骤：

1. 创建新网站，添加OEmbed发现。
2. 将网址发布到您网站上的表单。现在，您的网站代表我执行了OEmbed。

3. 利用漏洞：

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

这是最大的XSS，几乎没有停止它。唯一明智的做法是将正确的端点列入白名单。这是明确列出的oEmbed端点。

如果你想要一些可扩展的东西，你可能会喜欢www.noembed.com和www.embedly.com。他们为那些不自己做OEmbed的网站提供OEmbed支持。