I caricamenti di media sicuri scadono

Abbiamo un cliente che riscontra problemi con il caricamento di media protetti.
Questo cliente utilizza un’installazione ufficiale di Discourse basata su Docker, con AWS S3 e i media protetti abilitati.

Il forum contiene diversi file audio in formato mp3 e m4a.

Discourse incorpora automaticamente un player simile a questo:

image

Problema: i file audio non funzionano in modo affidabile. A volte non vengono riprodotti.

Non riesco a riprodurre il problema in modo completamente affidabile; penso sia dovuto alla cache, ma sembra che il download venga posticipato fino a quando non viene premuto il pulsante di riproduzione. Questo sembra logico e corretto.

Tuttavia, questo comportamento non è compatibile con i caricamenti di media protetti: se si lascia aperta una pagina per un po’ di tempo e si preme il pulsante di riproduzione dopo un minuto o più, il file audio non viene riprodotto (o non sempre). In quel momento, AWS restituisce un errore 403 Expired. Sembra che la richiesta non venga firmata al momento della richiesta del file, ma in un momento precedente. Il messaggio di errore indica chiaramente che la richiesta è scaduta in passato.

Sospetto che ciò sia legato al ritardo, ma non ne sono completamente certo. Il fatto è che questo problema si verifica solo con i file audio (non con le immagini incorporate, che vengono sempre scaricate immediatamente).

Sì, l’ora del server è corretta.

Posso riprodurre il problema su un’installazione fresca con l’ultima versione beta. Basta inserire due file audio in un argomento e fare qualche prova.

2 Mi Piace

Ciò potrebbe essere dovuto al modo in cui i browser gestiscono i tag audio e video e al valore predefinito di preload. I file sono particolarmente lunghi? Per quanto ne so, i browser scaricano utilizzando intervalli di byte su richiesta.

4 Mi Piace

No, non sono lunghi, i file sono solo pochi ( < 5) megabyte e non vengono scaricati per intervalli.

Cosa intendi per ‘il valore predefinito di preload’?

Se hai un tag <audio> o <video>, impostare l’attributo preload=auto su di esso suggerirà al browser di scaricarlo tutto al caricamento della pagina, così non avresti questo problema con la scadenza dell’URL firmato di S3.

Come spesso accade con queste cose, i siti hanno iniziato ad abusare di questo attributo e non viene più seguito ciecamente, ma è un suggerimento che il browser prenderà in considerazione.

6 Mi Piace

Non c’è un tag <audio> esplicito; viene generato automaticamente da Discourse quando viene inserito il file audio. Senza un attributo preload.

La parte che non capisco: se la rotta /secure-media-uploads genera l’URL firmato, perché dovrebbe importare quanto tempo passa tra il caricamento della pagina e l’accesso alla rotta? Dopo tutto, genera la rotta firmata e poi immediatamente reindirizza a quella. Eppure, sembra che in qualche modo faccia la differenza. Sembra che qualcosa venga messo in cache o altro?

C’è nell’HTML generato dal markdown del post, ed è di quello che sto parlando. Direi che ha senso aggiungere quell’attributo quando l’impostazione è abilitata.

Credo che l’intero punto della funzione sia proprio questo. Avere URL che non possono essere condivisi altrove per i caricamenti, e l’unico modo per farlo è utilizzare URL con scadenza.

5 Mi Piace

Sì, lo capisco. E il timer di scadenza inizia a contare nel momento in cui viene chiamato il route /secure-media-uploads, non quando la pagina viene caricata.

Tuttavia, sembra che importi se la pagina è stata caricata molto prima che il route venga raggiunto. E in quel caso si rompe, in qualche modo. Non riesco proprio a capire perché accada.

Questo è stato ora risolto qui https://github.com/discourse/discourse/commit/7ff58f17877cd5b5ce6e96def47aa7719e843977 @RGJ. Il problema si verificava perché i browser inviano una richiesta iniziale ai file audio e video per ottenere i metadati del file, ad esempio la durata. Tuttavia, a causa dell’URL firmato sicuro, questa richiesta iniziale avviava il conto alla rovescia di 15 secondi per la scadenza; quindi, quando gli utenti tentavano di riprodurre audio e video dopo tale lasso di tempo, ricevevano l’errore 403 da AWS.

Ora disabilitiamo il precaricamento per video e audio quando i media sicuri sono abilitati. I post esistenti con audio e video dovranno avere il loro HTML ricostruito per vedere la modifica.

13 Mi Piace