Yksityinen HLS-striimisi latautuu sinulle, ei katsojillesi

Testaat sivua kannettavallasi, soitin käynnistyy ja tiketti suljetaan. Katsoja toisessa päässä avaa saman sivun ja saa pyörivän ilmaisimen, joka ei koskaan ratkea. Tavallinen selitys on, että VPN on palvelimella, joten toiston pitäisi toimia — mutta juuri selain on komponentti, joka pyytää soittolistan, ja sillä on oma verkkopolkunsa. Palvelimelle, jolla on yksityinen pääsy, upotettu sivu ei lainaa sitä pääsyä sille, joka sen lataa.

Kyse on olemassa olevasta ASP.NET-sivusta, joka toistaa HLS-lähdettä kuten http://10.5.5.9:8080/live/stream.m3u8, joka on havainnollistava yksityinen osoite. Kaksi järjestelyä toimii; toinen niistä ei todennäköisesti ole se, jonka rakensit.

Myytti: latautuva sivu todistaa mediapolun

Sen sivun HTML tulee verkkopalvelimeltasi, sitä reittiä, joka verkkopalvelimellasi on. Soittolista ja segmentit tulevat median lähteestä, sitä reittiä, joka pyynnön tekevällä komponentilla on. Kun soitin pyörii katsojan selaimessa, kyse on kahdesta eri asiakkaasta, kahdesta eri lähdeosoitteesta ja usein kahdesta eri vikaantumisalueesta. Ensimmäisen onnistuminen ei kerro toisesta mitään.

Se, mitä testisi itse asiassa todisti, on kapeampaa kuin miltä näytti: koneesi pääsee sekä julkiselle sivulle että yksityiselle mediaisännälle samaan aikaan. Katsojan kone ei ollut koskaan osa koetta.

Mitä soittolista pyytää seuraavaksi

RFC 8216 erottaa mediasegmenttejä luettelevat mediasoittolistat pääsoittolistoista, jotka luettelevat muita soittolistoja, ja ratkaisee suhteelliset URI:t sen soittolistan URI:n suhteen, joka sisältää ne. Juuri se sääntö jää ihmisiltä väliin. Yhden .m3u8-tiedoston onnistunut hakeminen ei ole toistotesti, koska haettu tiedosto on hakemisto, ei media.

Seuraa ketjua niin kuin soitin tekee: avaa valittu soittolista, pyydä sitten sen nimeämät resurssit ja seuraa sitten mahdollisia uudelleenohjauksia. Saavutettavan verkkopalvelimen kautta tarjoiltu soittolista voi silti ohjata katsojan saavuttamattomaan yksityiseen osoitteeseen. Samoin suhteellisen soittolistan siirtäminen toiseen URL-osoitteeseen muuttaa sitä kantaa, jota vasten sen merkinnät ratkaistaan, ja siksi ensimmäisen näkyvän URL-osoitteen uudelleenkirjoittaminen ja siihen pysähtyminen tuottaa yleensä kelvolliselta näyttävän soittolistan, jota ei voi toistaa.

Suora katselu: katsoja tarvitsee polun

Jos katsojien on tarkoitus päästä mediaisäntään suoraan, heidän laitteensa tarvitsevat hyväksytyn VPN:n tai muun yksityisen polun, DNS:n, joka ratkaisee ne nimet, joita todella käytit, luvan päästä näihin kohteisiin ja kaiken sen todennuksen, jota mediipalvelu vaatii. Tarkista jokainen niistä katsojan laitteella, ei palvelimella. Selain puhelimessa, jossa VPN-profiili on asennettu mutta ei yhdistetty, on yleinen ja täysin toistettava vika.

Tämä järjestely pitää lähteen yksityisenä ja työntää pääsyvaatimuksen yleisölle. Se on yhtä lailla poliittinen kuin tekninen päätös, joten varmista ennen suunnittelua, että jokaisella aiotulla katsojalla on lupa pitää tätä polkua.

Palvelinpuolen toimitus: yksi valvottu sisääntulopiste

Vaihtoehto on valtuutettu mediaetuosa, joka hakee lähteen omaa yksityistä polkuaan pitkin ja julkaisee uudelleen vain katsojalle näkyvät resurssit. Pidä soittolista, segmentit ja mahdolliset avainresurssit yhdenmukaisina tämän yhden sisääntulopisteen kanssa, muuten soitin hakee uudelleenkirjoitetun soittolistan etuosan kautta ja segmentit suoraan osoitteesta, johon katsoja ei pääse.

Rajoita lähde ja sallitut polut siinä etuosassa. Käyttäjän antama mielivaltainen URL-osoite muuttaa hyödyllisen välityspalvelimen sisäverkkosi rajoittamattomaksi hakijaksi, mikä on paljon pahempi ongelma kuin striimi, joka ei toistu. Laita lähde ja polun etuliite sallittujen luetteloon sen sijaan, että validoisit merkkijonon jälkikäteen.

Olemassa olevan HLS-lähteen kohdalla tarkista ensin, riittääkö valvottu edelleenlähetys; VPN keskellä ei tarkoita, että transkoodaus olisi tarpeen. Validoi sitten todellinen selain- ja koodekkiyhdistelmä, koska saavutettava vastaus ja tuettu muoto ovat kaksi erillistä ehtoa. Pidä lähteen TLS, todennus ja selaimen turvavaatimukset ehjinä — upotettu soitin ei ole niistä vapautettu.

Testaa ketjua, älä URL-osoitetta

Suorita tarkistukset siitä komponentista, joka todella tekee jokaisen pyynnön, ja käsittele jokaista vaihetta omana tuloksenaan:

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

Toista se sitten katsojan omassa selaimessa aiottua striimiä käyttäen, ei työpöytäsi testikuviolla. Sivun lataus, soittolistan lataus, segmentin haku ja valtuutuksen epäonnistuminen ovat neljä erillistä tulosta, ja haluat nähdä kaikki neljä ennen kuin kutsut sitä korjatuksi. Älä asenna vanhentunutta selainliitännäistä siksi, että vanha esimerkki toisti yhden striimin niin; puuttuva pala on yleensä katsojan polku tai allekirjoittamaton segmentin URL-osoite.

Kun järjestely on tarkoituksellinen, kirjoita se yhdelle riville: kuka hakee median, mitä polkua pitkin ja mitä katsoja saa pyytää. Se lause ratkaisee useimmat tulevat kiistat siitä, kenelle striimi oikeastaan on tarkoitettu.