Decoupled web UI and server ports

[Nouser]

Explanation of the changes, problem that they are intended to fix.

tl;dr

New argument --videoport can be used to specify which port the video stream should be served from.

If unspecified, the behavior is unchanged and the video stream and the web UI will be served from the same port.

In-Depth Reasoning

The web UI is served from the same port as the video stream. This means that anyone with access to view your stream can also change your channel content, view your Plex library, upload files to the machine running Dizquetv, change settings for transcoders, or add watermarks to all your channels. While this is fine if you share your content only with trustworthy people, this is a limiting factor in making a Dizquetv instance open to anyone.

One step to helping make Dizquetv safer for use with untrusted viewers is to separate the ports you serve the web UI and the video stream from. This allows Dizquetv operators to lock down control of their programming while still allowing folks to view the channels they've created.

There is an open question I have in the code about if HDHR should also live on the same port as the video stream - I'm not well acquainted with its use, so I'd appreciate some guidance and can add it to the video stream's route if that's the path we want.

I haven't been able to fully test this by setting up a virtual local network and isolating some of the ports, but I did ensure that the content was playable from the specified port and that if no port is specified, it defaults to the web UI's port (as was the behavior before this change). I might be able to set this up for further testing if this feature is wanted.

...

All Submissions:

• I have read the code of conduct.
• I am submitting to the correct base branch

New features

• I understand that the feature may not be accepted if it doesn't fit the upstream app's planned design direction. But that in this case I am encouraged to share this as an available modification other users can use if they want.

[Nouser]

This addresses issue #465 . Sorry the commit history is a little wonky, I started from mainline instead of dev. Happy to resubmit starting from the right base branch if you'd like.

[vexorian]

Something like this is necessary. TBH I was kind of thinking the best solution is to use a proxy service like nginx. Though I never tried to do it on my own so I don't know how feasible it is to just do it with a proxy and routes without needing to change dizqueTV code.

An issue with this is that the distinction between "video" and "ui" is not enough unfortunately. hdhr is needed by Plex for auto detecting dizqueTV. Althoug I've been thinking of deprecating that feature since xteve can do it and dizqueTV does too many things at once already. But similar to hdhr issue is the TV guide. Technically, many clients do need access to the port that delivers the xmltv, so maybe it should be the same port as video? But then comes the problem that xmltv might be using images from the api port since there's' an image host in there. And that brings up to the other issue with images, many of the things inside the video streaming logic that make use of images use the api port (things like the channel watermarks, the loading screen and the error screen).

I don't have time right now to review it. Hope to do it Saturday, but it might be a good idea to start reviewing these potential questions on your own. Also these changes are likely going to go to dev/1.6.x, even if it currently doesn't exist, but don't worry, I can fix it once we decide to merge it. I do agree with giving the ability to separate the ports, but we need more analysis in regards to which port will do which endpoint.

[Nouser]

Thanks for the feedback! With these notes in mind, it feels like I have the solution flipped around. Maybe we should have the "UI" (and perhaps any other configuration routes) be on a separate port and everything else lives on another port. This way we still get the images, XMLTV, watermarks, etc. without much change.

Thinking out loud, since this is also a single application running on a single machine, we shouldn't have to worry too much about internally doing REST requests between the ports, only if the response gives some URL containing a port we don't necessarily have access to.

I'm going to try and lock down a virtual network to only surface one port and see where things start breaking as I move routes from one to the other. Even if this isn't the final answer, it lets us see the coupling a little more clearly. I'll try to report back any information I gather.

[hendrix04]

I would recommend making the ports not only be settable via an input parameter, but also by ENV variable with a hierarchy of command line > ENV > default.