Il tuo flusso HLS privato si carica per te, non per i tuoi spettatori

Provi la pagina sul portatile, il lettore parte e il ticket viene chiuso. Lo spettatore dall’altra parte apre la stessa pagina e ottiene un indicatore di caricamento che non si risolve mai. La spiegazione abituale è che la VPN è sul server, quindi la riproduzione dovrebbe funzionare — ma è il browser il componente che chiede la playlist, e ha il proprio percorso di rete. Una pagina incorporata su un server con accesso privato non presta quell’accesso a chi la carica.

Si tratta di una pagina ASP.NET esistente che riproduce una sorgente HLS come http://10.5.5.9:8080/live/stream.m3u8, che è un indirizzo privato illustrativo. Funzionano due disposizioni; una di esse probabilmente non è quella che hai costruito.

Mito: una pagina che si carica dimostra il percorso dei media

L’HTML di quella pagina arriva dal tuo server web, lungo qualunque percorso abbia il tuo server web. La playlist e i segmenti arrivano dall’origine dei media, lungo qualunque percorso abbia il componente che effettua la richiesta. Quando il lettore gira nel browser dello spettatore, questi sono due client diversi, due indirizzi di origine diversi e spesso due domini di errore diversi. Vedere il primo riuscire non dice nulla sul secondo.

Ciò che il tuo test ha davvero dimostrato è più stretto di quanto sembrasse: la tua macchina raggiunge insieme la pagina pubblica e l’host privato dei media. La macchina dello spettatore non è mai stata parte dell’esperimento.

Cosa chiede la playlist in seguito

RFC 8216 separa le playlist dei media, che elencano segmenti, dalle playlist master, che elencano altre playlist, e risolve gli URI relativi rispetto all’URI della playlist che li contiene. Proprio questa regola viene saltata. Scaricare con successo un file .m3u8 non è un test di riproduzione, perché il file scaricato è un indice, non i media.

Segui la catena come fa il lettore: apri la playlist selezionata, poi richiedi le risorse che nomina, poi segui qualsiasi reindirizzamento. Una playlist servita tramite un server web raggiungibile può comunque mandare lo spettatore a un indirizzo privato irraggiungibile. Allo stesso modo, spostare una playlist relativa su un altro URL cambia la base rispetto alla quale vengono risolte le sue voci, ed è per questo che riscrivere il primo URL visibile e fermarsi lì produce di solito una playlist che sembra valida ma non può essere riprodotta.

Visione diretta: lo spettatore ha bisogno del percorso

Se gli spettatori devono raggiungere direttamente l’host dei media, i loro dispositivi hanno bisogno della VPN approvata o di un altro percorso privato, di un DNS che risolva i nomi che hai effettivamente usato, del permesso di raggiungere quelle destinazioni e di qualsiasi autenticazione richieda il servizio media. Verifica ciascuna cosa sul dispositivo dello spettatore e non sul server. Un browser su un telefono con il profilo VPN installato ma non connesso è un guasto frequente e del tutto riproducibile.

Questa disposizione mantiene privata l’origine e sposta il requisito di accesso sul pubblico. È una decisione politica oltre che tecnica, quindi conferma che ogni spettatore previsto possa tenere quel percorso prima di progettare intorno ad esso.

Consegna lato server: un unico punto di ingresso controllato

L’alternativa è un frontend media autorizzato che recupera l’origine lungo il proprio percorso privato e ripubblica solo le risorse rivolte allo spettatore. Mantieni la playlist, i segmenti e qualsiasi risorsa chiave coerenti con quel singolo punto di ingresso, altrimenti il lettore scaricherà una playlist riscritta attraverso il frontend e i segmenti direttamente da un indirizzo che lo spettatore non può raggiungere.

Limita l’origine e i percorsi consentiti in quel frontend. Un URL arbitrario fornito dall’utente trasforma un proxy utile in un recuperatore illimitato della tua rete interna, che è un problema molto peggiore di un flusso che non si riproduce. Metti l’origine e il prefisso del percorso in una lista di autorizzati invece di validare la stringa a posteriori.

Per una sorgente HLS esistente, verifica prima se l’inoltro controllato è sufficiente; una VPN in mezzo non implica che serva la transcodifica. Poi valida la combinazione reale di browser e codec, perché una risposta raggiungibile e un formato supportato sono due condizioni distinte. Mantieni intatti TLS, autenticazione e requisiti di sicurezza del browser dell’origine — un lettore incorporato non ne è un’eccezione.

Verifica la catena, non l’URL

Esegui i controlli dal componente che farà davvero ogni richiesta e tratta ogni passaggio come il suo risultato:

curl -s http://10.5.5.9:8080/live/stream.m3u8
curl -s -o /dev/null -w '%{http_code}\n' http://10.5.5.9:8080/live/segment-000123.ts

Poi ripetilo nel browser dello spettatore stesso con il flusso previsto, non con un modello di prova dalla tua scrivania. Caricamento della pagina, caricamento della playlist, recupero del segmento e un errore di autorizzazione sono quattro esiti distinti, e vuoi averli osservati tutti e quattro prima di dichiararlo risolto. Non installare un plugin del browser obsoleto perché un vecchio esempio riproduceva così un flusso; il pezzo mancante di solito è il percorso dello spettatore o l’URL del segmento non firmato.

Quando la disposizione è deliberata, scrivila in una riga: chi recupera i media, attraverso quale percorso e cosa è consentito chiedere allo spettatore. Quella frase risolve la maggior parte delle discussioni future su per chi è davvero il flusso.