oEmbed API端點和URL方案與鏈接標記有什麼不同？

Question

的oEmbed規範中提到2種不同的發現一個URL的透過oEmbed內容的方式：

1. 知道該網站的API端點和傳遞，通過GET參數，網址，您想了解的信息，如果它匹配它聲明的URL模式。
2. 通過<link rel="alternate" type="application/json+oembed" ... />（或text/xml+oembed）HTML標題發現oEmbed版本的URL。

第二種方式似乎更通用，因爲您不必存儲和維護整個供應商列表。此外，提供商名單是中央互聯網的標誌，只有少數演員存在。這種方法難以擴展。

雖然我可以看到第一種方法的用途，但對於可以解析其他人可用的資源的網站來說。例如，我可以從網站Foo提供一個oEmbed版本的視頻頁面。但是，由於以下幾個原因，主要是與安全有關，我不會相信某人說「我可以爲你解析資源X」，除非X的作者確定了這一點，這使我們回到了方法2.

所以我的問題是：我在這裏錯過了什麼？第一種處理oEmbed的方法有什麼用？例如，爲什麼要存儲（並保持最新的）一系列端點和模式，如果您有一種通用的方式來發現它並且幾乎可以在互聯網上使用任何資源？

作爲一個非常密切相關的問題，我認爲可能同時被問到（如果我錯了，請糾正我）：如果沒有爲oEmbed內容提供中央端點，會發生什麼情況，比如說，期望每個URL都有一個'？version = oembed'參數，它會返回oEmbed版本而不是標準版本？

Answer 1

我希望在這裏找到答案，但看起來其他人都和我們一樣困惑。在我看來，使用選項1的好處是，它只使用1個json請求，而不是使用json請求後可能需要的HTML請求。您可以始終使用選項2作爲回退，以防您無法匹配oEmbed提供程序的預先列出的列表中的模式。

Answer 2

如果我沒有記錯，支持這兩種機制是一種妥協，我們認爲這將有助於推動採用。說服大型web屬性添加單個端點與向每個響應主體添加標記（對大多數客戶無關）要容易得多。這是一個實用的選擇。

從長遠來看，我們計劃利用Eran Hammer-Lahav在發現過程中所做的一些工作，而不是重新發明它（再次糟糕）。不幸的是，他的想法仍然沒有得到太多的牽引，網絡仍然缺乏一個好的，標準化的方式來做這種事情。

Answer 3

OEmbed發現是一個主要的安全問題。 WordPress例如有一個支持OEmbed提供商的白名單。

假設互聯網上的每個隨機URL都可以觸發OEmbed代碼。這意味着每個人都可以破解你的網站。

步驟：

1. 創建一個新的網站，添加一個透過oEmbed發現。
2. 將URL發佈到您網站的表單。現在您的網站代表我執行OEmbed。

3. 利用漏洞：

   • 通過拒絕服務（DOS）：例如的URL重定向到一個那tarpit或給它一個1GB JSON響應。
   • 通過跨站腳本（XSS）：注入隨機HTML到其他人可以看到的頁面。
   • 偷通過XSS管理員的會話cookie的：現在攻擊者可以登錄到您的CMS上傳文件，並利用甚至更多。

這是XSS到了極致，幾乎沒有停止它。做唯一理智的事情是將適當的端點列入白名單。這是oembed端點明確列出。

如果你想要的東西可擴展的，你可能會喜歡www.noembed.com和www.embedly.com他們提供了哪些不做透過oEmbed自己的各種網站透過oEmbed支持。