Váš soukromý HLS stream se načítá pro vás, ne pro vaše diváky

Stránku otestujete na notebooku, přehrávač se spustí a tiket se zavře. Divák na druhé straně otevře stejnou stránku a dostane spinner, který se nikdy nedořeší. Obvyklé vysvětlení zní, že VPN je na serveru, takže přehrávání musí fungovat — ale právě prohlížeč je komponenta, která si seznam skladeb vyžaduje, a má vlastní síťovou cestu. Stránka vložená na server s privátním přístupem tento přístup nepůjčuje tomu, kdo ji načte.

Jde o existující stránku ASP.NET, která přehrává zdroj HLS, například http://10.5.5.9:8080/live/stream.m3u8, což je ilustrativní privátní adresa. Fungují dvě uspořádání; jedno z nich pravděpodobně není to, které jste postavili.

Mýtus: načtená stránka dokazuje cestu k médiím

HTML té stránky přichází z vašeho webového serveru, po trase, kterou váš webový server má. Seznam skladeb a segmenty přicházejí z mediálního zdroje, po trase, kterou má komponenta odesílající požadavek. Když přehrávač běží v prohlížeči diváka, jsou to dva různí klienti, dvě různé zdrojové adresy a často dvě různé domény selhání. To, že první uspěje, neříká o druhém nic.

Co váš test vlastně dokázal, je užší, než to vypadalo: váš stroj dosáhne na veřejnou stránku i na privátní mediální hostitel zároveň. Stroj diváka nikdy součástí experimentu nebyl.

Co si seznam skladeb vyžádá dál

RFC 8216 odděluje mediální seznamy skladeb, které vypočítávají segmenty, od hlavních seznamů skladeb, které vypočítávají jiné seznamy, a řeší relativní URI vůči URI seznamu, který je obsahuje. Právě toto pravidlo lidé přeskakují. Úspěšné stažení jednoho souboru .m3u8 není test přehrávání, protože stažený soubor je index, ne média.

Sledujte řetěz tak, jak to dělá přehrávač: otevřete zvolený seznam, pak si vyžádejte zdroje, které pojmenovává, a pak následujte jakékoli přesměrování. Seznam vydávaný přes dostupný webový server může diváka přesto nasměrovat na nedostupnou privátní adresu. Stejně tak přesun relativního seznamu na jinou URL mění základnu, vůči které se jeho položky řeší, a proto přepsání první viditelné URL a zastavení na tom obvykle vytvoří seznam, který vypadá platně, ale nelze jej přehrát.

Přímé sledování: divák potřebuje cestu

Pokud mají diváci dosáhnout na mediálního hostitele přímo, jejich zařízení potřebují schválenou VPN nebo jinou privátní cestu, DNS, které řeší jména, jež jste skutečně použili, oprávnění dosáhnout na tyto cíle a jakoukoli autentizaci, kterou mediální služba vyžaduje. Ověřte každou položku na zařízení diváka, ne na serveru. Prohlížeč v telefonu s nainstalovaným, ale nepřipojeným profilem VPN je častá a zcela reprodukovatelná porucha.

Toto uspořádání udržuje zdroj v soukromí a přenáší požadavek na přístup na publikum. Je to rozhodnutí o politice stejně jako o technice, takže před návrhem potvrďte, že každý zamýšlený divák smí tuto cestu mít.

Doručení ze serveru: jeden řízený vstupní bod

Alternativou je autorizovaný mediální frontend, který zdroj stáhne po své privátní cestě a znovu publikuje jen prostředky určené divákovi. Udržujte seznam, segmenty a případné klíčové prostředky v souladu s tímto jediným vstupním bodem, jinak přehrávač stáhne přepsaný seznam přes frontend a segmenty přímo z adresy, na kterou divák nedosáhne.

Omezte zdroj a povolené cesty v tomto frontendu. Libovolná URL zadaná uživatelem mění užitečný proxy na neomezený stahovač vaší vnitřní sítě, což je mnohem horší problém než stream, který se nepřehraje. Dejte zdroj a prefix cesty na seznam povolených, místo abyste řetězec ověřovali dodatečně.

U existujícího zdroje HLS nejprve ověřte, zda stačí řízené předávání; VPN uprostřed neznamená, že je nutné překódování. Pak ověřte skutečnou kombinaci prohlížeče a kodeku, protože dostupná odpověď a podporovaný formát jsou dvě oddělené podmínky. Zachovejte TLS, autentizaci a bezpečnostní požadavky prohlížeče na straně zdroje nedotčené — vložený přehrávač z nich není vyjmut.

Testujte řetěz, ne URL

Spouštějte kontroly z komponenty, která skutečně odešle každý požadavek, a každý krok berte jako vlastní výsledek:

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

Pak to zopakujte v prohlížeči samotného diváka s určeným streamem, ne s testovacím vzorem ze svého stolu. Načtení stránky, načtení seznamu, stažení segmentu a selhání autorizace jsou čtyři odlišné výsledky a chcete vidět všechny čtyři, než to prohlásíte za opravené. Neinstalujte zastaralý doplněk prohlížeče jen proto, že starý příklad takto přehrál jeden stream; chybějící díl je obvykle cesta diváka nebo nepodepsaná URL segmentu.

Jakmile je uspořádání záměrné, zapište ho jedním řádkem: kdo stahuje média, po jaké cestě a co smí divák žádat. Ta věta vyřeší většinu budoucích sporů o to, pro koho je stream vlastně určen.