It looks like all images from fanc.tmsimg.com are loaded over HTTP. Aside from that, it works perfectly behind a reverse proxy for me.
This is the key to fixing the jsonpipe. I think you may need to move it into the location /
block like in @LukeLambertās example
well thanks for the cookie auth, that part works great. but the guide view does not show the scheduled recordings when viewing on an iPhone, or when using Safari on macos.
Hmm, I hadnāt noticed that. Disabling HTTP/2 seems to fix it. Iāve updated my example conf.
thank you so much for pointing this out! my conf is slightly different than yours, I was just using your cookie auth, which is great. But I had no idea that http2 was incompatible with iPhone and Safari like this! I had to turn off http2 for everything using the same ip and port (which took a bit of searching). But I got it!
Finally, a fully working dvr over https, using my own cert!
@tmm1 : edit: was going to suggest an nginx conf as a feature, but just remembered how many different devices you have developed for that are now compatible with channels.
Thanks for tracking it down. I recall seeing the same behavior before.
What was the required line in the nginx conf? I didnāt see any changes in the example.
it was previously: listen [port] ssl http2;
the hidden issue is that if this is say, port 443, and there is anything other service set to use http2 over port 443 (this would be common for a reverse proxy), then it will be used by default for every other service listening on that port.
Iāve added experimental HTTPS support to the DVR starting in v2017.07.20.1616. Each DVR installation will automatically generate a unique self-signed certificate, and publish the fingerprint of that certificate as part of its bonjour service.
HTTP and HTTPS both share the same port, so to force SSL connections simply change the URL to https://
If you want, you can also swap out the generated cert for your own, by replacing cert.pem
and key.pem
in the channels-dvr/data/
directory.
Thatās GREAT news!!! Hmmā¦but can you implement a different port for HTTPS, say port 8090? Because when we do port forwarding, we cannot differentiate between https and HTTP. Iād just want to allow https only. Could you please implement different port? Otherwise, itās no use at all.
If you only use https it shouldnāt matter that http is also available.
But other people from outside can choose to connect using http, right? Iād like to block http from outside world completely.
Yes but all they would see is the login page. There is zero difference if you see the login page over http or https
I donāt see login page. Both http or https would bring me directly into Channel DVR web page.
I could be wrong, but I think your public IP address is also considered a local address to Channels DVR. i.e. You wonāt be prompted to authenticate from any request originating from your network, even if you access the admin using your public IP address.
Try accessing it from your phone with wifi turned off in a private browser window. I was concerned until I tried that.
The login page is only shown when you try to access the DVR from the internet. Also once you login you wonāt see it again unless you clear cookies.
So yea check from cellular connection in a private browsing window and youāll see itās the same for http and https. All https does is encrypt the traffic, so when you do login no one sit in between you and your DVR and sniff your login details.
I was able to use a certificate generated from Letās Encrypt project. Thanks.
Okay so Iāve setup the DVR using https with a cert from letsencrypt. Iād be happy to expose my box to the internet via my own domain (DDNS setup with router port forwarding just to the DVR linux box). Do any ports other than 8089 need to be forwarded to the box for the streaming in the web client?
Also detection of the DVR on the local network for the Channels client apps relies upon bonjour, right? Any chance we could use a server address instead/aswell on a client device? That way a client device could connect from the internet without having to resort to a VPN. I could take my aTV away with me and still access my recordings and live TV as long as the bandwidth is good enough. Obviously this doesnāt relate specifically to https per se but is just something else I thought about.
Iāve been able to connect over https with my own certificates from Letās Encrypt, and it seems to be working fine. The only thing Iāve noticed is that when you start to play live TV or a recording, the padlock disappears in the web browserās address bar. Is this expected behaviour?
Nope.
Remote streaming support in the tvOS and iOS apps is planned.
Looks like the video player loading image was being downloaded over http. Fixed for the next build.