Jou private HLS-stroom laai vir jou, nie vir jou kykers nie

Jy toets die bladsy op jou skootrekenaar, die speler begin, en die kaartjie word toegemaak. Die kyker aan die ander kant maak dieselfde bladsy oop en kry ’n draaikring wat nooit ophou nie. Die gewone verduideliking wat aangebied word, is dat die VPN op die bediener is, so die afspeling behoort te werk — maar dit is die blaaier wat die snitlys aanvra, en dit het sy eie netwerkpad. ’n Bladsy wat op ’n bediener met private toegang gehuisves word, leen nie daardie toegang aan enigiemand wat dit laai nie.

Dit gaan oor ’n bestaande ASP.NET-bladsy wat ’n HLS-bron soos http://10.5.5.9:8080/live/stream.m3u8 speel, wat ’n illustratiewe private adres is. Twee reëlings werk; een van hulle is waarskynlik nie wat jy gebou het nie.

Mite: ’n laaiende bladsy bewys die mediapad

Die HTML vir daardie bladsy kom van jou webbediener, oor watter roete jou webbediener ook het. Die snitlys en die segmente kom van die media-oorsprong, oor watter roete die aanvraende komponent ook het. Wanneer die speler in die kyker se blaaier loop, is daardie twee verskillende kliënte, twee verskillende bronadresse en dikwels twee verskillende foutdomeine. Om die eerste te sien slaag, sê jou niks oor die tweede nie.

Wat jou toets werklik bewys het, is smaller as wat dit gelyk het: jou masjien kan die openbare bladsy en die private media-gasheer op dieselfde tyd bereik. Die kyker se masjien was nooit deel van die eksperiment nie.

Wat die snitlys volgende vra

RFC 8216 skei media-snitlyste, wat segmente lys, van meestersnitlyste, wat ander snitlyste lys, en dit los relatiewe URI’s op teen die URI van die snitlys wat hulle bevat. Daardie reël is die deel wat mense oorslaan. Om een .m3u8-lêer suksesvol te haal, is nie ’n afspelingstoets nie, want die lêer wat jy gehaal het, is ’n indeks, nie die media nie.

Volg die ketting soos die speler dit doen: maak die gekose snitlys oop, vra dan die hulpbronne aan wat dit noem, en volg dan enige herleiding. ’n Snitlys wat deur ’n bereikbare webbediener gelewer word, kan die kyker steeds na ’n onbereikbare private adres wys. Net so verander die skuif van ’n relatiewe snitlys na ’n ander URL die basis waarteen sy inskrywings opgelos word, en dit is waarom die herskryf van die eerste sigbare URL en om daar te stop gewoonlik ’n geldig-lykende snitlys lewer wat nie kan speel nie.

Direkte kyk: die kyker het die pad nodig

As kykers die media-gasheer direk moet bereik, het hul toestelle die goedgekeurde VPN of ’n ander private pad nodig, DNS wat die name oplos wat jy werklik gebruik het, toestemming om daardie bestemmings te bereik, en watter verifikasie die mediadiens ook vereis. Kontroleer elkeen op die kyker se toestel eerder as op die bediener. ’n Blaaier op ’n selfoon met die VPN-profiel geïnstalleer maar nie gekoppel nie, is ’n algemene en heeltemal herproduseerbare fout.

Hierdie reëling hou die bron privaat en skuif die toegangsvereiste na die gehoor. Dit is ’n beleidsbesluit net soveel as ’n tegniese een, so bevestig dat elke beoogde kyker toegelaat word om daardie pad te hou voordat jy daarom ontwerp.

Bedienerkant-lewering: een beheerde toegangspunt

Die alternatief is ’n gemagtigde media-frontend wat die bron oor sy private pad haal en slegs die kyker-gerigte hulpbronne herpubliseer. Hou die snitlys, die segmente en enige sleutelhulpbronne in ooreenstemming met daardie enkele toegangspunt, anders sal die speler ’n herskrewe snitlys oor die frontend haal en die segmente regstreeks vanaf ’n adres wat die kyker nie kan bereik nie.

Beperk die bron en die toegelate paaie in daardie frontend. ’n Gebruiker-verskafte willekeurige URL verander ’n nuttige gevolmagtigde in ’n onbeperkte haalder van jou interne netwerk, wat ’n veel erger probleem is as ’n stroom wat nie sal speel nie. Lys die oorsprong en die padvoorvoegsel as toegelate, eerder as om die string agterna te valideer.

Vir ’n bestaande HLS-bron, kyk eers of beheerde deurstuur genoeg is; ’n VPN in die middel beteken nie dat transkodering nodig is nie. Valideer dan die werklike blaaier- en kodekkombinasie, want ’n bereikbare antwoord en ’n ondersteunde formaat is aparte voorwaardes. Hou die oorsprong se TLS-, verifikasie- en blaaierveiligheidsvereistes ongeskonde — ’n ingebedde speler is nie ’n vrystelling daarvan nie.

Toets die ketting, nie die URL nie

Voer die kontroles uit vanaf die komponent wat werklik elke versoek sal maak, en behandel elke stap as sy eie resultaat:

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

Herhaal dit dan in die kyker se eie blaaier met die bedoelde stroom, nie ’n toetspatroon van jou lessenaar nie. Bladsy-laai, snitlys-laai, segment-ophaling en ’n magtigingsfout is vier afsonderlike uitkomste, en jy wil al vier waargeneem hê voordat jy dit as reg beskou. Moenie ’n ou blaaier-inprop installeer omdat ’n ou voorbeeld een stroom so gespeel het nie; die ontbrekende deel is gewoonlik die kyker se pad of die ongetekende segment-URL.

Sodra die reëling doelbewus is, skryf dit in een reël neer: wie die media haal, oor watter pad, en wat die kyker toegelaat word om aan te vra. Daardie sin besleg die meeste toekomstige argumente oor vir wie die stroom werklik bedoel is.