rP18140 made it so that the Server identifies the "host" (able to kick...) by listening to clients telling it they're the host. Yes, this is as secure as it sounds.
elexis rightfully raised a concern with it, suggesting that client and server should instead share a secret that the client uses to authenticate itself.
I agree, and in the short term the simplest secret is "I'm in the same process as you are". #3953 was concerned with data racesThis does that, but this is safeby generating a GUID appropriately.
Here's the breakdown of things:
- The client handshakes.
- The server generates a GUID and sends it to the client (handshake response).
- The client receives that response, sets m_GUID, then sends an Authenticate request to the server
- The server receives the authenticate request, compares the GUID with that of g_NetClient, and assigns host-ness.
It is thus rather obvious that the server cannot read from m_GUID while it is being written to, nor before it is written to.
ThisIt partly reverts rP18140.
---
One might wonder how this interacts with dedicated servers (#3556)This is an obvious step towards dedicated servers (#3556), as those will require some mechanism of identifying a client as controller.
You can experience being host or not by running the patch below and starting with `-dedicated` . It doesn'tYou can then join a game on your local network and be controller. For one thingIf you add a `-dedicated-secret`, dedicated servers don't start a clientyou'll still be able to join the game, so the point is somewhat mootbut not as a controller, and dedicated serverssince you don't really need a host able to ban players so much as a players being able to vote or somethinghave the secret.
_should_ we want dedicated-servers-host to be able to start a "host" client, we probably should go the whole way to an actual 'i am host' secret{F1742368}
(this obviously needs more for proper dedicated servers, but this is un-necessary for nowat covers the authentication issue).