oEmbed规范提到了查找URL的oEmbed内容的两种不同方法:
- 知道网站的API端点，并通过GET参数传递你想要的URL信息，如果它与它声明的URL模式匹配。
- 通过
<link rel="alternate" type="application/json+oembed" ... />(或text/xml+oembed) HTML头发现oEmbed版本的URL。
第二种方法似乎更通用，因为您不需要存储和维护整个提供者列表。此外，提供商列表是集中式互联网的标志，只有少数参与者存在。这种方法很难扩展。
我可以看到第一种方法的使用，但是，对于可以解析由其他人提供的资源的网站。例如，我可以提供一个oEmbed版本的视频页面从网站Foo。然而，出于几个原因，主要是与安全相关的原因，我不会相信那些说"我可以为您解析资源X"的人，除非X的作者同意这样做，这让我们回到方法2。
所以我的问题是:我错过了什么?处理oEmbed的第一种方法的用途是什么?例如，如果您有一种即时发现的通用方法，并且可以查找internet上几乎任何资源，那么为什么还要像oohEmbed那样存储(并保持最新)整个端点和模式列表呢?
作为一个非常密切相关的问题，我认为可能会同时问(请纠正我，如果我错了):如果不为oEmbed内容提供一个中心端点，而是说，期望一个'?version=oembed'参数在每个URL上，返回oembed版本而不是标准的一个?
如果我没记错的话，支持两种机制是一种折衷，我们认为这将有助于推动采用。说服大型web属性添加单个端点比向每个响应体添加标记(这与大多数客户端无关)要容易得多。这是一个务实的选择。
从长远来看，我们计划利用Eran Hammer-Lahav围绕发现所做的一些工作，而不是重新发明它(再次糟糕)。不幸的是，他的想法仍然没有得到太多的关注，网络仍然缺乏一个好的、标准化的方式来做这类事情。
我希望在这里找到一个答案，但看起来其他人都和我们一样困惑。在我看来，使用选项1的好处是它只使用一个json请求，而不是一个潜在的昂贵的html请求，然后是json请求。如果你无法匹配预焙的oEmbed提供程序列表中的模式，你可以使用选项2作为备用方案。
嵌入式发现是一个主要的安全问题。例如，WordPress有一个支持OEmbed提供商的白名单。
假设互联网上的每个随机URL都可以触发OEmbed代码。这意味着每个人都可以入侵你的网站。
步骤:
- 创建新站点，添加OEmbed发现
- 将URL发布到您站点的表单中。现在你的网站代表我执行OEmbed。
-
利用:
通过拒绝服务(DOS):例如，将URL重定向到一个tarpit或给它一个1GB的json响应。 - 通过跨站点脚本(XSS):向其他人可以看到的页面注入随机HTML。通过XSS窃取管理员的session-cookie:现在攻击者可以登录到你的CMS上传文件，并利用更多。
这是最大的XSS，几乎没有阻止它。唯一相同的做法是将适当的端点列入白名单。这就是oEmbed端点被显式列出。
如果你想要一些可扩展的东西，你可能会喜欢www.noembed.com和www.embedly.com他们为各种不支持OEmbed的网站提供OEmbed支持