Conversation
… and healthchecks to work
…server docker often bypasses firewalls like UFW in Linux meaning that if running on a server without binding to localhost it could lead expose your instance
|
Binding directly to localhost isn't the norm and should be left to the user as most of the time, Docker is being used on headless VPS/servers. I think it'd be valuable in the readme as a hint though. |
So surely if it's being used primarily on headless VPS/servers where there often isn't a network level firewall binding to localhost is imperative because Docker bypasses the standard firewall for Ubuntu servers (UFW) leaving them exposed |
I must also add that currently if you change the port in the .env file Chatmock won't work because the docker-compose never checks environment variables, furthermore health checks aren't configured to work on any non-standard port. If you want to revert the binding then so be it but the port mapping itself is a necessity |
I'm just another user so I don't really have control over it, but I just know that most of the time, if it's being run on Docker, it's usually headless vs GUI, so defining it to localhost by default would be counter-intuitive to most. Also the firewall thing is UFW-Docker specific, which they provide documentation for advising users that UFW is incompatible altogether, so I'd assume most people would be using a network firewall or behind NAT? I just think it would be better in the readme than by default for new user experience. |
Most people do not know this, it is not common knowledge and why would you want to bind to 0.0.0.0 anyway? I can't think of a single reason unless you weren't networking with Docker properly. If you're running it on a VPS and want to expose it I'd hope you're not just binding to 0.0.0.0 and if you are then everyone can potentially access your Chatmock instance. The way you should expose it would be with a Wireguard or Cloudflare tunnels such that Chatmock is added to their docker network and they can access Chatmock - which is isolated from everything else. But if like me you just want to run it on your own machine with Docker then you'd also want to bind to localhost. If you have an opportunity to make the world more secure why wouldn't you? If the user really knows what they're doing, enough to be tinkering, then a simple binding isn't going to confuse them in any way. If it does then they probably shouldn't be meddling. Regardless of all this silly discussion though the main patch affects the issue where you could change the port in your .env file and it would break Chatmock |
2 participants
Port mapping didn't work with docker because the environment variables were never used for port mapping or health checks. I also bound to localhost to ensure nobody exposes their instance if their network doesn't have a firewall as Docker tends to bypass firewalls at an operating system level