I'm currently working on a best practice implementation for mjpg-streamer and OctoPrint. Best would be to by default have the mjpg-streamer stream password-protected and bound to localhost/127.0.0.1 to restrict access as much as possible. However, OctoPrint seems to not being able to deal with both:
- In case of password-protection, the URL would need to contain credentials, like
http://user:password@host/?action=stream, but if I got it right, this is already prevented on browser-level: https://github.com/OctoPrint/OctoPrint/issues/3056
While I cannot reproduce a related browser console error, I can at least verify, that it does not work for the stream in OctoPrint. As fast as credentials are removed, it works fine.
- Now, if no password-protection is possible, it would at least great to have mjpg-streamer bound to the loopback IP to prevent any non-local access. While this is perfectly possible at mjpg-streamer side via
-i 'output_http.so -l 127.0.0.1', OctoPrint fails to connect to the Stream when using
127.0.0.0/8IP. This is btw independent from whether mjpg-streamer is actually bound to any IP or not, OctoPrint seems to simply deny using any local IP, it seems. This is btw not an issue I found just by myself, but while I was able to verify, other users reported this already, so it is not related to my system or network.
- Taking both together, I currently fail to achieve a secure setup with OctoPrint + mjpg-streamer.
Interestingly, snapshots work in both cases, but I think those are cached?
- I tried multiple IP bindings, "localhost" and many
127.0.0.0/8IPs, checked browser console and OctoPrint logs, but the failing stream connection does not even create a log entry.
- I verified that otherwise access to the stream via local browser works fine, including
sudo -u octoprint curl http://127.0.0.1:8082/?action=streamto rule out any user permissions issue.
GET http://127.0.0.1:8082/?action=stream&1612704601611 net::ERR_CONNECTION_REFUSED
- Debian (any)
- OctoPrint freshly installed via Python 3 pip.
- mjpg-streamer self-compiled.
Actually while writing/copying the browser error here, the underlying problem became clear (EDIT: Okay, it's even stated in the web UI settings !):
- The connection to the webcam stream is not done from OctoPrint (i.e. locally), but from the browser, which accesses remotely. Using a loopback host, makes the browser hence accessing itself, which of course can only fail.
- It is hence necessary currently to use the remote and in case public hostname/IP for webcam access.
- This is problematic, because it breaks the ability to e.g. control OctoPrint with webcam stream remotely without exposing the bare webcam stream, without even password-protection, remotely as well.
- It would be reasonable (but I have no idea if/how to achieve it) when OctoPrint would not present the webcam as resource to be requested by the browser, but would internally do the request locally (or within the local network) and stream it to the browser through the OctoPrint connection. Excuse my probably wrong wording here, I hope you get the idea.
But as neither bound webcam streams nor password-protection is possible, how do you guys setup a secure OctoPrint + webcam stream, or is it them simply not possible currently?