4 Stimmen

Was ist der Sinn von oEmbed-API-Endpunkten und URL-Schemata im Vergleich zu Link-Tags?

En oEmbed Spezifikation werden 2 verschiedene Möglichkeiten genannt, den oEmbed-Inhalt einer URL zu finden:

  1. Kenntnis des API-Endpunkts der Website und Übergabe der gewünschten URL über einen GET-Parameter, wenn sie mit dem angegebenen URL-Muster übereinstimmt.
  2. Ermitteln der URL der oEmbed-Version dank einer <link rel="alternate" type="application/json+oembed" ... /> (oder text/xml+oembed ) HTML-Kopfzeile.

Der 2. Weg scheint allgemeiner zu sein, da man nicht eine ganze Liste von Anbietern speichern und pflegen muss. Außerdem sind Listen von Anbietern ein Zeichen für ein zentralisiertes Internet, in dem es nur wenige Akteure gibt. Dieser Ansatz ist kaum skalierbar.

Ich kann mir jedoch vorstellen, dass der 1. Ansatz für Websites, die von anderen zur Verfügung gestellte Ressourcen analysieren können, von Nutzen ist. Ich kann zum Beispiel eine oEmbed-Version von Videoseiten der Website Foo anbieten. Aus verschiedenen Gründen, vor allem aus Sicherheitsgründen, würde ich jedoch niemandem trauen, der sagt: "Ich kann Ressource X für Sie analysieren", es sei denn, der Autor von X ist damit einverstanden, was uns wieder zu Ansatz 2 bringt.

Meine Frage ist also: Was habe ich hier verpasst? Welchen Nutzen hat die 1. Methode im Umgang mit oEmbed? Warum sollte man zum Beispiel eine ganze Liste von Endpunkten und Mustern speichern (und aktuell halten)? wie oohEmbed es tut wenn Sie eine generische Möglichkeit haben, sie im Handumdrehen und für praktisch jede Quelle im Internet zu finden?

Eine damit eng zusammenhängende Frage, die meines Erachtens gleichzeitig gestellt werden könnte (bitte korrigieren Sie mich, wenn ich falsch liege): Was passiert, wenn man keinen zentralen Endpunkt für oEmbed-Inhalte bereitstellt, sondern, sagen wir, einen Parameter '?version=oembed' auf jeder URL erwartet, der die oEmbed-Version anstelle der Standardversion zurückgibt?

4voto

mmalone Punkte 1751

Wenn ich mich recht erinnere, war die Unterstützung beider Mechanismen ein Kompromiss, von dem wir annahmen, dass er die Akzeptanz fördern würde. Es ist viel einfacher, große Web-Properties davon zu überzeugen, einen einzigen Endpunkt hinzuzufügen, als Markup (das für die meisten Kunden irrelevant ist) zu jedem Antwortkörper hinzuzufügen. Es war eine pragmatische Entscheidung.

Längerfristig wollten wir einige der Arbeiten von Eran Hammer-Lahav im Bereich der Entdeckung nutzen, anstatt sie (wieder einmal) neu zu erfinden. Leider haben sich seine Ideen noch immer nicht durchgesetzt, und dem Web fehlt noch immer eine gute, standardisierte Methode, um solche Dinge zu tun.

1voto

Bonnici Punkte 1576

Ich hatte gehofft, hier eine Antwort zu finden, aber wie es aussieht, sind alle anderen genauso verwirrt wie wir. Der Vorteil der Verwendung von Option 1 ist meiner Meinung nach, dass es nur 1 json-Anfrage anstelle einer potenziell teuren html-Anfrage gefolgt von der json-Anfrage verwendet. Sie können immer Option 2 als Fallback verwenden, falls Sie ein Muster in Ihrer vorgefertigten Liste der oEmbed-Anbieter nicht finden können.

0voto

vdboor Punkte 20756

Die Erkennung von OEmbed ist ein großes Sicherheitsproblem. WordPress hat zum Beispiel eine Whitelist der unterstützten OEmbed-Anbieter.

Nehmen wir an, dass jede beliebige URL im Internet einen OEmbed-Code auslösen kann. Das bedeutet, dass jeder Ihre Website hacken kann.

Schritte:

  1. Erstellen Sie eine neue Website, fügen Sie eine OEmbed-Erkennung hinzu.
  2. Geben Sie die URL in ein Formular auf Ihrer Website ein. Jetzt führt Ihre Website die OEmbed in meinem Namen durch.
  3. Ausnutzen:

    • durch Denial-of-Service (DOS): z.B. Umleitung der URL auf einen Tarpit oder Einspeisung einer 1GB json-Antwort.
    • durch Cross-Site-Scripting (XSS): Einspeisung von zufälligem HTML in Seiten, die andere Personen sehen können.
    • durch Diebstahl des Session-Cookies des Administrators über XSS: Jetzt kann sich der Angreifer in Ihr CMS einloggen, um Dateien hochzuladen und noch mehr auszunutzen.

Das ist XSS in Reinkultur, und es gibt kaum Möglichkeiten, das zu verhindern. Das einzig Vernünftige, was man tun kann, ist das Whitelisting der richtigen Endpunkte. Das ist die oEmbed Endpunkte sind explizit aufgeführt.

Wenn Sie etwas Skalierbares wollen, könnten Sie www.noembed.com und www.embedly.com mögen. Sie bieten OEmbed-Unterstützung für verschiedene Websites, die selbst kein OEmbed anbieten.

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X