Nous avons un client qui rencontre des problèmes avec les téléversements de médias sécurisés.
Ce client exécute une installation officielle de Discourse basée sur Docker avec AWS S3 et les médias sécurisés activés.
Le forum contient plusieurs fichiers sonores mp3 et m4a.
Discourse intègre automatiquement un lecteur élégant comme celui-ci :
Problème : les fichiers sonores ne fonctionnent pas de manière fiable. Parfois, ils ne se lisent pas.
Je ne parviens pas à reproduire ce problème à 100 %, probablement en raison de la mise en cache, mais il semble que le téléchargement soit reporté jusqu’à ce que le bouton de lecture soit appuyé. Cela semble logique et judicieux.
Cependant, cela ne fonctionne pas bien avec les téléversements de médias sécurisés : si vous laissez une page ouverte pendant un certain temps et que vous appuyez sur le bouton de lecture après une minute ou plus, le fichier sonore ne se lit pas (toujours). À ce moment-là, AWS renvoie une erreur 403 Expired. Il semble que la requête ne soit pas signée au moment où le fichier est demandé, mais plus tôt. Le message d’erreur indique clairement que la requête a expiré dans le passé.
Je soupçonne que cela est lié au délai, mais je n’en suis pas absolument certain. Le fait est que cela ne concerne que les fichiers sonores (et non les images intégrées, qui sont toujours téléchargées immédiatement).
Oui, l’heure du serveur est correcte.
Je peux reproduire le problème sur une installation fraîche exécutant la dernière version bêta. Il suffit de placer deux fichiers sonores dans un sujet et de faire quelques essais.
Cela peut être dû au fonctionnement des navigateurs avec les balises audio et vidéo et à la valeur par défaut de preload. Les fichiers sont-ils particulièrement longs ? À ma connaissance, les navigateurs téléchargent en utilisant des plages d’octets à la demande.
Si vous avez une balise <audio> ou <video>, définir un attribut preload=auto sur celle-ci indiquera au navigateur de tout télécharger lors du chargement de la page, ce qui éviterait ce problème d’expiration de l’URL signée S3.
Comme c’est souvent le cas avec ces fonctionnalités, les sites ont commencé à abuser de cet attribut, et il n’est plus toujours suivi aveuglément, mais reste un indice que le navigateur prendra en compte.
Ce que je ne comprends pas : si la route /secure-media-uploads génère l’URL signée, pourquoi le délai entre le chargement de la page et l’appel à cette route importe-t-il ? Après tout, elle génère la route signée puis redirige immédiatement vers celle-ci. Pourtant, il semble que cela ait de l’importance. On dirait que quelque chose est mis en cache ou autre chose du genre ?
Il y en a une dans le HTML généré à partir du markdown du message, et c’est de cela que je parle. Je dirais qu’il est logique d’ajouter cet attribut lorsque le paramètre est activé.
Je pense que l’objectif même de cette fonctionnalité est exactement cela. Avoir des URLs qui ne peuvent pas être partagées ailleurs pour les téléchargements, et la seule façon d’y parvenir est d’utiliser des URLs qui expirent.
Oui, je comprends cela. Et le minuteur d’expiration commence à compter au moment où la route /secure-media-uploads est appelée, et non lorsque la page est chargée.
Pourtant, il semble que cela ait de l’importance si la page a été chargée bien avant que la route ne soit atteinte. Et alors, cela plante, d’une manière ou d’une autre. Je ne comprends simplement pas pourquoi cela se produit.
Cela a maintenant été corrigé ici FIX: Disable preloading audio + video when secure media enabled (#8922) · discourse/discourse@7ff58f1 · GitHub@RGJ. Le problème se produisait parce que les navigateurs envoient une requête initiale vers les fichiers audio et vidéo pour récupérer les métadonnées du fichier, par exemple la durée. Cependant, en raison de l’URL signée sécurisée, cette requête initiale déclenchait le compte à rebours de 15 secondes avant expiration. Ainsi, lorsque les utilisateurs tentaient de lire l’audio ou la vidéo après ce délai, nous recevions une erreur 403 de la part d’AWS.
Nous désactivons désormais le préchargement pour les vidéos et les fichiers audio lorsque le média sécurisé est activé. Les publications existantes contenant de l’audio ou de la vidéo devront voir leur HTML reconstruit pour que ce changement prenne effet.
