Reverse proxy and web player

Channels DVR Server Troubleshooting
#1

I have a fully working Channels DVR with a preverse proxy and Lets Encrypt Certifcate.
When I try to watch Live-TV and Recording, it does not work.

Someone seems to have hardcoded url-scheme, hostname and port... Which results in Mixed-Content-Error (http content in https site). Please change m3u8 URL in VideoPlayer.jsx relative to request URL like so : "//dvr/files/4470/hls/stream.m3u8?params"

Then Channels Web Player is agnostic what reverse proxy settings and hostname i have.
I fixed this for now with enabling "insecure content" for my DVR website in Chrome. But this results in a red label "insecure" at the website, so this is not a real fix.
I would like to NOT have to let nginx change the content of the http response of Channels with the http_sub_module to correct the error, so a fix is highly appreciated.
Here the error from Chrome Console:
VideoPlayer.jsx:132 Mixed Content: The page at 'https://tv.xxxxx.com/admin/shows/11102883-de' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://10.0.2.14:8089/dvr/files/4470/hls/stream.m3u8?abitrate=256&abr=false&achannels=6&acodec=aac&bitrate=9744&resolution=1080&ssize=1&vcodec=h264'. This request has been blocked; the content must be served over HTTPS.

Thank you!

1 Like
#2

I'm in the same boat. I could enable insecure content, but I'd rather not.

#3

Sad that this topic gets no attention by anyone except zchrykng :frowning:
As this a basic web development error to produce mixed content tls-wise.
I should have asked about a different color for a button, a died hard drive or some other silly question than we would see like 20 responses....

#4

I don't understand what you're expecting us to do. The URL we specify in the player is relative.

The URLs returned by the master.m3u8 are not, to allow them to function properly when the m3u8 is downloaded and played (for instance, by VLC).

If the connection comes to us over SSL, we return an https URL, if the connection comes to us over plain HTTP, we return an http URL. The DVR is not intended to be used from behind a proxy (there are lots of ways in which setting it up behind a proxy can defeat the security mechanisms we have in place) and there isn't much I can see that we could do to handle your situation even if we wanted to prioritize it.

1 Like
#5

I've been using a reverse proxy for ages without issues.
Can fix by simply modifying your proxy server configuration.

#6

very simple:
dont return
http://10.0.2.14:8089/devices/ANY/channels/6500/hls/stream.m3u8?abr=false&acodec=copy&bitrate=7200&indexed=true&ssize=1&vcodec=copy
if i click on play in the guide. Instead return just
//devices/ANY/channels/6500/hls/stream.m3u8?abr=false&acodec=copy&bitrate=7200&indexed=true&ssize=1&vcodec=copy

This is just a rephrase of my 1st post, there are more details.

  • removes all mixed content errors if reverse proxy is https
  • keeps the requests consistently going thorugh reverse proxy and not bypasses them

why i am using a reverse proxy:

  • i want to use a proper, short and nice fqdn
  • i dont want to add the awkward port number 8089 to the address
  • i dont want red insecure warnings in my browser
#7

We can’t do that because if you downloaded the m3u8 and tried to play it in VLC (which is a thing that our current user base really does) it would try to play file:// and fail.

#8

Maybe there is a misunderstanding, I am talking about the "Watch Now" button:

image
image2358×982 237 KB

EDIT:
besides that your point still isnt valid, as // will be replaced with protocol://hostname/ anyways automatically with the appropatiate values from the request headers in the frontend.

#9

It appears we've reached the end of the useful discussion on this topic. We aren't going to be changing how it works and we've explained why it works the way that it does.

If you need more details, please search the forum for VLC to discover why this is the way that it is.

#10