I’m currently working on a multiplayer game which will be using two databases(MONGODB). One for authentication(login) and one to contain all game-specific data.
What I’ve done is to separate the user and game specific data. This way i’ll be able to build micro services around the user in the future.
I’m a bit uncertain on how to handle/validate the game-specific database operations tho.
When i log into my game, i perform a POST request to my rest api, which validates the user and returns some data.
The game itself however, is using a TCP socket connection to handle real-time gameplay and will be saving game-specific data to the database on the authoritative server(all game logic is done on the server) . How would you go about to link the data on the game-specific database to a specific user found in the authentication database?
I think generating a private/public key in the auth-service and send it (with a token) encrypted through the client and then uncrypt it and match the userId on the serverside might be the way to go.
I dont know the coding, but yhea, I think that would be a way to go. Or, maybe it could save some CPU cycle if instead its the encrypted information that should be stored in the server side?
For example, the client sends the information encrypted and then match the userID (stored in its encrypted form) in the serverside, so no decryption is needed just matching. I think this way, it might help reduce hacking the user information as the culprit dont know which is which just in case of an attack to the server. Also, it could save the server CPU cycles if you got maybe thousands of users simultaneously accessing.
I would just arrange for the login server to return a UUID that can be used by subsequent operations. Presumably, the game-server can query the authentication server (if necessary) to determine if this particular UUID is valid.
I’ve thought about this approach as well, however, that would mean that I’d have to save the UUID on the user & perform database operations to be able to retrieve it from the game server and I’d much rather save it in memory on the game server straight away if that would’ve been possible, which led me off this approach.
But perhaps it’s better if I worry about optimization later and just perform the database operation once for each user login, then save the token in memory on the game server by mapping it to a player and handle it from there.
I think that, if you think about it, you’ll see that it is quite necessary to hold UUID information on the client side, since it is quite impossible(!) to meaningfully hold it on the server side.
This UUID is, so to speak, “the client’s calling card.” Handed to it by the server upon successful login, it is utterly meaningless to the client, yet it must be presented as a part of each-and-every subsequent request. The server (by means of which the client knows-not and cares-not …) must thereafter accept the presented UUID-credential as “valid evidence that ‘I represent a logged-in user.’”
As you can plainly see, it is utterly impossible for an imposter to present a credential that would be accepted by the server. Nor is it possible for anyone (other than the server …) to know which login a particular acceptable-credential represents.
