Jo privee HLS-stream wurdt foar dy laden, net foar dyn sjoggers

Do testest de side op dyn laptop, de spiler start en it ticket wurdt sletten. De sjogger oan de oare kant iepenet deselde side en krijt in draaikrús dat nea oplost. De gewoane ferklearring is dat de VPN op de tsjinner stiet, dus de ôfspiling soe wurkje moatte — mar it is de browser dy't de ôfspylist opfreget, en hy hat syn eigen netwurkpaad. In side dy't ynbêde is op in tsjinner mei privee tagong, lienet dy tagong net oan wa't him laden.

Dit giet oer in besteande ASP.NET-side dy't in HLS-bron ôfspilet lykas http://10.5.5.9:8080/live/stream.m3u8, dat in yllustrative privee adres is. Twa opstellings wurkje; ien fan har is wierskynlik net dy'tsto boud hast.

Myt: in ladende side bewiist it mediapaad

De HTML fan dy side komt fan dyn webserver, oer hokker rûte dyn webserver ek hat. De ôfspylist en de segminten komme fan de mediabron, oer hokker rûte de oanfreegjende komponint ek hat. As de spiler yn de browser fan de sjogger rint, binne dat twa ferskillende klanten, twa ferskillende boarneadressen en faaks twa ferskillende flaterdomeinen. It slagjen fan it earste seit neat oer it twadde.

Wat dyn test eins bewiisde, is smeller as it like: dyn masine kin tagelyk de iepenbiere side en de privee mediahost berikke. De masine fan de sjogger wie nea part fan it eksperimint.

Wat de ôfspylist dêrnei freget

RFC 8216 skiedt media-ôfspylisten, dy't segminten listje, fan master-ôfspylisten, dy't oare listen listje, en lost relative URI’s op tsjin de URI fan de list dy't se befettet. Krekt dy regel slaan minsken oer. Ien .m3u8-bestân mei sukses helje is gjin ôfspilingstest, want it bestân datst helst is in yndeks, net de media.

Folgje de keatling sa't de spiler it docht: iepenje de keazen ôfspylist, freegje dan de boarnen op dy't er neamt, folgje dan elke trochstjoering. In ôfspylist tsjinne troch in berikbere webserver kin de sjogger dochs nei in ûnberikber privee adres stjoere. Likegoed feroaret it ferpleatsen fan in relative ôfspylist nei in oare URL de basis dêr't har ynfieringen tsjin oplost wurde, en dêrom jout it oerskriuwen fan de earste sichtbere URL en dêr ophâlde meastentiids in jildich-lykjende ôfspylist dy't net ôfspylje kin.

Direkt sjen: de sjogger hat it paad nedich

As sjoggers de mediahost direkt berikke moatte, hawwe har apparaten de goedkarde VPN of in oar privee paad nedich, DNS dat de nammen oplost dy'tsto echt brûkt hast, tastimming om dy bestimmingen te berikken, en hokker autentikaasje de mediatsjinst ek freget. Kontrolearje elk op it apparaat fan de sjogger ynstee fan op de tsjinner. In browser op in tillefoan mei it VPN-profyl ynstallearre mar net ferbûn is in gongbere en folslein werhellbere flater.

Dizze opstelling hâldt de boarne privee en skoot de tagongseis nei it publyk. It is in beliedsbeslissing likefolle as in technyske, dat befêstigje dat elke bedoelde sjogger dat paad hâlde mei foardatst deromhinne ûntwerpst.

Levering fan de tsjinnerkant: ien kontrolearre yngongspunt

It alternatyf is in autorisearre media-frontend dy't de boarne oer syn privee paad hellet en allinnich de boarnen wer publisearret dy't de sjogger sjocht. Hâld de ôfspylist, de segminten en eventuele kaailboarnen konsistint mei dat iene yngongspunt, oars hellet de spiler in oerskreaune ôfspylist fia de frontend en de segminten streekrjocht fan in adres dat de sjogger net berikke kin.

Behein de boarne en de tastiene paden yn dy frontend. In willekeurige URL fan de brûker makket in handige proxy ta in ûnbeheinde heljer fan dyn ynterne netwurk, dat is in folle slimmer probleem as in stream dy't net ôfspilet. Set de boarne en it paadfoarheaksel op in tastiene list ynstee fan de tekenrige efterôf te falidearjen.

Besjoch foar in besteande HLS-bron earst oft kontrolearre trochstjoering genôch is; in VPN yn it midden betsjut net dat transkodearjen nedich is. Falidearje dan de wiere kombinaasje fan browser en kodek, want in berikber antwurd en in stipe formaat binne twa aparte betingsten. Hâld TLS, autentikaasje en browserfeiligenseasken fan de boarne yntakt — in ynbêde spiler is dêr gjin útsûndering op.

Test de keatling, net de URL

Fier de kontrôles út fan de komponint dy't echt elk fersyk docht, en behannelje elke stap as syn eigen 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

Werhelje it dan yn de browser fan de sjogger sels mei de bedoelde stream, net mei in testpatroan fan dyn buro. It laden fan de side, fan de ôfspylist, it heljen fan it segmint en in mislearre autorisaasje binne fjouwer ferskillende útkomsten, en do wolst alle fjouwer sjoen hawwe foardatst it repareare neamst. Ynstallearje gjin ferâldere browser-útwreiding om't in âld foarbyld sa ien stream ôfspile; it ûntbrekkende stik is meastentiids it paad fan de sjogger of de ûnûndertekene URL fan it segmint.

As de opstelling bewust is, skriuw him dan yn ien rigel del: wa't de media hellet, oer hokker paad, en wat de sjogger freegje mei. Dy sin beslist de measte takomstige diskusjes oer foar wa't de stream echt bedoeld is.