Vaš zasebni tok HLS se naloži za vas, ne za vaše gledalce

Stran preizkusite na prenosniku, predvajalnik se zažene in zahtevek se zapre. Gledalec na drugi strani odpre isto stran in dobi vrtavko, ki se nikoli ne razreši. Običajna razlaga je, da je VPN na strežniku, zato bi predvajanje moralo delovati — a prav brskalnik je komponenta, ki zahteva seznam predvajanja, in ima svojo omrežno pot. Stran, vdelana na strežnik z zasebnim dostopom, tega dostopa ne posodi tistemu, ki jo naloži.

Gre za obstoječo stran ASP.NET, ki predvaja vir HLS, na primer http://10.5.5.9:8080/live/stream.m3u8, kar je ponazoritveni zasebni naslov. Delujeta dve postavitvi; ena od njih verjetno ni tista, ki ste jo zgradili.

Mit: naložena stran dokazuje medijsko pot

HTML te strani prihaja z vašega spletnega strežnika, po kateri koli poti, ki jo ima vaš spletni strežnik. Seznam predvajanja in segmenti prihajajo iz medijskega vira, po kateri koli poti, ki jo ima komponenta, ki pošilja zahtevo. Ko predvajalnik teče v brskalniku gledalca, sta to dva različna odjemalca, dva različna izvorna naslova in pogosto dve različni domeni napak. To, da prvi uspe, ne pove ničesar o drugem.

Kar je vaš test v resnici dokazal, je ožje, kot je bilo videti: vaš stroj doseže hkrati javno stran in zasebnega gostitelja medijev. Gledalčev stroj nikoli ni bil del poskusa.

Kaj seznam predvajanja zahteva naprej

RFC 8216 ločuje medijske sezname predvajanja, ki naštevajo segmente, od glavnih seznamov, ki naštevajo druge sezname, in razrešuje relativne URI glede na URI seznama, ki jih vsebuje. Prav to pravilo ljudje preskočijo. Uspešno pridobivanje ene datoteke .m3u8 ni preizkus predvajanja, ker je pridobljena datoteka kazalo, ne medij.

Sledite verigi tako, kot to počne predvajalnik: odprite izbrani seznam, nato zahtevajte vire, ki jih navaja, nato sledite vsaki preusmeritvi. Seznam, postrežen prek dosegljivega spletnega strežnika, lahko gledalca še vedno usmeri na nedosegljiv zasebni naslov. Prav tako premik relativnega seznama na drug URL spremeni osnovo, glede na katero se razrešujejo njegovi vnosi, in zato prepisovanje prvega vidnega URL-a in ustavljanje tam običajno ustvari seznam, ki je videti veljaven, a ga ni mogoče predvajati.

Neposredno gledanje: gledalec potrebuje pot

Če naj bi gledalci dosegli gostitelja medijev neposredno, njihove naprave potrebujejo odobreni VPN ali drugo zasebno pot, DNS, ki razrešuje imena, ki ste jih res uporabili, dovoljenje za doseganje teh ciljev in kakršno koli preverjanje pristnosti, ki ga zahteva medijska storitev. Vsako od teh preverite na gledalčevi napravi in ne na strežniku. Brskalnik v telefonu z nameščenim, a nepriključenim profilom VPN je pogosta in popolnoma ponovljiva napaka.

Ta postavitev ohranja vir zaseben in zahtevo po dostopu potisne na občinstvo. To je politična odločitev prav toliko kot tehnična, zato potrdite, da sme vsak predvideni gledalec imeti to pot, preden oblikujete okoli nje.

Dostava s strežnika: ena nadzorovana vstopna točka

Alternativa je pooblaščen medijski sprednji del, ki vir pridobi po svoji zasebni poti in znova objavi samo vire, obrnjene h gledalcu. Vzdržujte seznam, segmente in morebitne ključne vire usklajene s to eno vstopno točko, sicer bo predvajalnik pridobil prepisan seznam prek sprednjega dela, segmente pa neposredno z naslova, ki ga gledalec ne doseže.

Omejite vir in dovoljene poti v tem sprednjem delu. Poljuben URL, ki ga vnese uporabnik, spremeni koristen posrednik v neomejenega pridobivalca vašega notranjega omrežja, kar je veliko hujši problem kot tok, ki se ne bo predvajal. Vnesite vir in predpono poti na seznam dovoljenih, namesto da bi niz preverjali naknadno.

Pri obstoječem viru HLS najprej preverite, ali zadošča nadzorovano posredovanje; VPN v sredini ne pomeni, da je potrebno prekodiranje. Nato preverite dejansko kombinacijo brskalnika in kodeka, ker sta dosegljiv odgovor in podprt format dva ločena pogoja. Ohranite TLS, preverjanje pristnosti in varnostne zahteve brskalnika vira nedotaknjene — vdelan predvajalnik ni izjema od njih.

Preizkusite verigo, ne URL

Izvedite preverjanja iz komponente, ki bo v resnici izvedla vsako zahtevo, in vsak korak obravnavajte kot njegov lastni rezultat:

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

Nato to ponovite v gledalčevem brskalniku s predvidenim tokom, ne s preizkusnim vzorcem z vaše mize. Nalaganje strani, nalaganje seznama, pridobivanje segmenta in neuspeh avtorizacije so štirje različni izidi, in želite videti vse štiri, preden to razglasite za popravljeno. Ne nameščajte zastarelega vtičnika brskalnika zato, ker je stari primer tako predvajal en tok; manjkajoči del je običajno gledalčeva pot ali nepodpisan URL segmenta.

Ko je postavitev namerna, jo zapišite v eni vrstici: kdo pridobi medije, po kateri poti in kaj sme gledalec zahtevati. Ta stavek razreši večino prihodnjih razprav o tem, za koga je tok v resnici namenjen.