Ein Kunde hat Probleme mit sicheren Medien-Uploads.
Dieser Kunde betreibt eine Docker-basierte Discourse-Installation (offizielles Installationspaket) mit AWS S3 und aktivierten sicheren Medien.
Das Forum enthält mehrere MP3- und M4A-Audiodateien.
Discourse integriert automatisch einen schönen Player wie diesen:
Problem: Die Audiodateien funktionieren nicht zuverlässig. Manchmal werden sie nicht abgespielt.
Ich kann das Problem nicht zu 100 % konsistent reproduzieren, vermutlich aufgrund von Caching. Es scheint jedoch, dass der Download erst verzögert erfolgt, wenn auf die Wiedergabetaste geklickt wird. Das klingt logisch und gut.
Allerdings verträgt sich das nicht gut mit sicheren Medien-Uploads: Wenn man eine Seite eine Weile offen lässt und erst nach einer Minute oder so auf die Wiedergabetaste klickt, wird die Audiodatei nicht (immer) abgespielt. In diesem Fall gibt AWS einen 403 Expired-Fehler zurück. Es sieht so aus, als wäre die Anfrage zum Zeitpunkt des Abrufs der Datei nicht signiert, sondern bereits früher. Die Fehlermeldung besagt eindeutig, dass die Anfrage in der Vergangenheit abgelaufen ist.
Ich vermute, dass dies mit der Verzögerung zusammenhängt, bin mir aber nicht zu 100 % sicher. Fakt ist, dass dies nur bei Audiodateien auftritt (nicht bei eingebetteten Bildern, die immer sofort heruntergeladen werden).
Ja, die Serverzeit ist korrekt.
Ich kann das Problem auf einer frischen Installation mit der neuesten Beta-Version reproduzieren. Einfach zwei Audiodateien in ein Thema einfügen und ein bisschen herumprobieren.
Das könnte daran liegen, wie Browser mit den Audio- und Video-Tags und dem Standardwert von preload umgehen. Sind die Dateien besonders lang? AFAIK laden Browser bei Bedarf über Byte-Range-Anfragen herunter.
Wenn du ein <audio>- oder <video>-Tag hast, kannst du das Attribut preload=auto setzen. Dies gibt dem Browser einen Hinweis, die Datei beim Laden der Seite vollständig herunterzuladen, sodass du dieses Problem mit dem Ablauf der signierten S3-URL nicht hättest.
Wie das bei solchen Dingen oft der Fall ist, haben Seiten begonnen, dieses Attribut zu missbrauchen, und es wird nicht mehr immer blind befolgt, sondern ist lediglich ein Hinweis, den der Browser berücksichtigt.
Es gibt kein explizites <audio>-Tag; es wird von Discourse automatisch generiert, wenn die Audiodatei eingefügt wird, ohne ein preload-Attribut.
Der Teil, den ich nicht verstehe: Wenn die Route /secure-media-uploads die signierte URL generiert, warum spielt es dann eine Rolle, wie viel Zeit zwischen dem Laden der Seite und dem Aufruf der Route vergeht? Schließlich generiert sie die signierte Route und leitet dann sofort dorthin weiter. Aber irgendwie scheint es doch eine Rolle zu spielen. Es scheint, als würde etwas zwischengespeichert oder ähnliches?
Im generierten HTML aus dem Post-Markdown ist es enthalten, und genau darüber spreche ich. Ich finde, es ergibt Sinn, dieses Attribut hinzuzufügen, wenn die Einstellung aktiviert ist.
Ich bin der Ansicht, dass genau dies der Kernpunkt der Funktion ist. Es geht darum, URLs für Uploads zu haben, die nicht anderweitig geteilt werden können, und die einzige Möglichkeit, dies zu erreichen, besteht in der Verwendung von ablaufenden URLs.
Ja, das verstehe ich. Der Ablauf-Timer beginnt genau dann zu laufen, wenn die Route /secure-media-uploads aufgerufen wird, und nicht, wenn die Seite geladen wird.
Dennoch scheint es eine Rolle zu spielen, ob die Seite lange vor dem Aufruf der Route geladen wurde. Und dann funktioniert es irgendwie nicht mehr. Ich verstehe nur nicht, warum das passiert.
Dies wurde hier behoben: FIX: Disable preloading audio + video when secure media enabled (#8922) · discourse/discourse@7ff58f1 · GitHub@RGJ. Das Problem trat auf, weil Browser eine initiale Anfrage an Audio- und Videodateien senden, um Metadaten wie die Dauer zu erhalten. Da jedoch eine sichere, signierte URL verwendet wurde, startete diese initiale Anfrage den 15-Sekunden-Ablaufzähler. Wenn Nutzer Audio oder Video nach Ablauf dieser Frist abspielen wollten, erhielten wir von AWS den Fehler 403.
Wir haben nun das Vorschauen-Laden (Preloading) für Video und Audio deaktiviert, sobald sichere Medien aktiviert sind. Bestehende Beiträge mit Audio und Video müssen neu aufgebaut werden, damit die Änderung wirksam wird.
