Currently, the encoder requires the use of the user's streamer credentials in order to push encoded videos to the streamer. This is problematic for a few reasons:
There is an issue of user passwords floating around, which is bad from a security perspective.
If the streamer opts to use Kerberos or SAML for auth, then that would break the encoder integration. As it is now, you can't use Kerberos or SAML for auth because of this encoder integration approach.
If you use the Active Directory plugin, AD passwords can get stored to log files, which most enterprise security folks would throw a fit about.
There are a few options that would address these concerns:
Instead of http, use a filesystem volume shared between the encoder and streamer to transfer both video metadata and the encoded file itself.
Use browser-side JS to send the metadata to the streamer at the time of upload, and a filesystem volume to transfer the encoded file. The browser-side JS upload lets you use the login cookie of the streamer instead of needing the password on the encoder server.
Option 1 is probably the ideal/fancy option, but I feel like option 2 is an reasonable interim option. My proposal is this:
In both the streamer and encoder configuration.php, add an option to specify a shared volume for transferring encoded videos from the encoder to the streamer.
When the encoder finishes encoding a video, it can drop a json file with the video metadata, as well as the actual encoded video in that volume. The metadata file would include the username of the uploader, but not the password. The metadata file will also have an assigned ID (e.g. GUID).
The encoder would then trigger an unauthenticated URL on the streamer to tell the streamer to check the volume for the new video data (by the metadata GUID). E.g. https://streamer/upload?metadataID={GUID}.
When the streamer gets the completion notification for the GUID, it will check the volume, and import that metadata file into the database, and transfer the encoded files to the videos directory.
From a security perspective, this is just establishing system-level trust between the encoder and streamer via the volume.
Currently, the encoder requires the use of the user's streamer credentials in order to push encoded videos to the streamer. This is problematic for a few reasons:
There are a few options that would address these concerns:
Option 1 is probably the ideal/fancy option, but I feel like option 2 is an reasonable interim option. My proposal is this:
From a security perspective, this is just establishing system-level trust between the encoder and streamer via the volume.