Problem in DM mit OpenAPI - Video Player Container-API

Wenn Sie die Funktion Dynamic Media mit offenen APIs [ 0] verwenden und den zurückgegebenen Code verwenden, um den Viewer von einer externen Website unverändert anzuzeigen, generiert der Code falsch formatierte URLs, um Videodetails abzurufen, und funktioniert nicht.

[ 0]  https://developer.adobe.com/experience-cloud/experience-manager-apis/api/stable/assets/delivery/#operation/videoPlayerDelivery

Beschreibung description

Beschreibung : Wenn ich die Dokumentation hier abnehme:
https://developer.adobe.com/experience-cloud/experience-manager-apis/api/stable/assets/delivery/#operation/videoPlayerDelivery

und das Fenster „Anfrage/Antwort“ auf der rechten Seite verwenden
Dokumentation zum Testen eines Video-Assets und Zurückgeben des Codes
Ich denke, ich kann die folgenden Bedenken reproduzieren:

Für den Bucket verwende ich: „delivery-pxxxxx-eyyyyy“ (aktivierte DMwOA-Versand-Domain)
Aus Sicherheitsgründen verwende ich „none“, um das Beispiel einfach zu halten und dies zu zeigen
Sicherheit ist nicht der Grund für die Besorgnis.
Für assetId verwende ich „urn:aaid:aem:aaaaaaa-bbb-cccc-ddd-eeeeeeeeee“ (gültige und genehmigte assetID)

Wenn ich die generierte Antwort darauf verwende, sehe ich in Zeile 157:
let origin = window.location.origin;
Dies führt zu dem Fehler, der in der Miniaturanfrage angezeigt wird
in Zeile 160 und in der Manifestanfrage in Zeile 174 seit
window.location.origin wird nicht vom Versandserver bereitgestellt
"https://delivery-pxxxxx-eyyyyyyy.adobeaemcloud.com", aber von Ihrem eigenen
Webserver wie erwartet. Es sollte „Let
origin="https://delivery-pxxxxx-eyyyyyy.adobeaemcloud.com" ' oder
Versandserver, der mit der Anfrage gesendet wurde.

Ist das ein Bug? Was ist die Empfehlung?

Auflösung resolution

Was Sie sehen, wird erwartet:
・ Der Code, der vom Video-Player-Bereitstellungsvorgang zurückgegeben wird, ist eine feste
HTML-Vorlage, die enthält

let origin = window.location.origin;
… fetch(${origin}/adobe/assets/…)

Es wird bewusst davon ausgegangen, dass es von demselben Host gerendert wird, der
dient den Streams, nämlich der Bereitstellungsebene (für Ihren Test-Bucket)
Das wäre https://delivery-pxxxxx-eyyyyyy.adobeaemcloud.com).
・ Wenn Sie dieses Snippet über das Swagger-Bedienfeld „Probieren Sie es aus“ ausführen (das
läuft auf developer.adobe.com) oder fügen Sie es in Ihre eigene Website,
window.location.origin entspricht nicht mehr dem Versandhost. Die Miniaturansicht
und Manifestabrufe gehen daher an den falschen Ursprung und 404/
CORS-Fehler.
・ Das Verhalten des Versanddienstes selbst ist korrekt. Das Problem ist
Nur mit , wo das Beispiel ausgeführt wird. Weil /play ein IFrame ist
Convenience-Wrapper Er kann den richtigen Host nicht kennen, wenn er außerhalb des
Versanddomäne.
Empfohlene Methode zum Testen oder Einbetten eines gebrandeten Players:

(Siehe Bereitstellungs-API-Dokumente: Bereitstellungs-APIs.)
Wenn Sie /play weiterhin verwenden müssen, müssen Sie den iframe vom hosten
Domain delivery-pxxxxx-eyyyyy oder passen Sie die generierte HTML an, sodass
Der Ursprung ist für diesen Host hartcodiert.