Thank you for an amazing product.
Currently one has to listen on an IP:port which makes the security reliant on Emby implementation. If you reverse proxy from Caddy, nginx, Envoy to Emby, you might introduce better proven security externally, but Emby is still listening on a LAN port that exposes it. If you want traffic between reverse proxy and Emby to be shielded from MITM, you will have to add TLS to Emby as well and manage certificate renewals on both Emby and reverse proxy. It can be somewhat mitigated by listening at 127.0.0.1:port, but then containerizing becomes a hassle as now you have to run Emby and reverse proxy in the same pod.
Listening on unix domain socket will resolve all these problems by just sharing the socket between container with Emby and container with reverse proxy (or if both are run non-containerized - without exposing Emby at port at all).
Kindly consider supporting listening on unix domain socket, please.
Thank you for an amazing product.
Currently one has to listen on an IP:port which makes the security reliant on Emby implementation. If you reverse proxy from Caddy, nginx, Envoy to Emby, you might introduce better proven security externally, but Emby is still listening on a LAN port that exposes it. If you want traffic between reverse proxy and Emby to be shielded from MITM, you will have to add TLS to Emby as well and manage certificate renewals on both Emby and reverse proxy. It can be somewhat mitigated by listening at 127.0.0.1:port, but then containerizing becomes a hassle as now you have to run Emby and reverse proxy in the same pod.
Listening on unix domain socket will resolve all these problems by just sharing the socket between container with Emby and container with reverse proxy (or if both are run non-containerized - without exposing Emby at port at all).
Kindly consider supporting listening on unix domain socket, please.