Sign In Register

How can we help you today?

Start a new topic
Answered

External Dedicated Server and Writes to Player Data

Hello,


We use an external dedicated server. We know that generally a player can read/write their own data and read other players data. Is it possible to have our players to be able to read ONLY their data, but have our dedicated servers after a matched write any player data updates?


Thanks!


Best Answer

Hi Derek,


The control of how a player interacts with their own data is on the application level, that being, it is up to you to decide how your system interacts with the player data. There is no way to "forbid" writes to the player, but it is possible to restrict the interface to the player data on the application level through LogEvents and using the REST API. 


-Pádraig


Answer

Hi Derek,


The control of how a player interacts with their own data is on the application level, that being, it is up to you to decide how your system interacts with the player data. There is no way to "forbid" writes to the player, but it is possible to restrict the interface to the player data on the application level through LogEvents and using the REST API. 


-Pádraig


1 person likes this

Ah, okay.

I may need to look into GSparks a bit more then. I would have assumed that only an "admin" like user would be able to successfully modify data. 


So, what about this situation then. If I no dedicated server, and clients connected to a host-client. At the end of a match, this host client would calculate and submit the score of each player and GSparks could update all players this way? If this is true, what stops a tech savy player from hijacking their session and altering this "match end" event?

Well if you are using your dedicated server as the go-between (Client<->DedServ<->GameSparks), they wouldn't know the connection to gamesparks since that is on your server.

Thanks for the reply, Christopher.


I tried to explain in my last reply though a situation where there was no dedicated server and a client acted as the server.

Ah, I thought the "no" was a typo for "on", my bad. There's a few good topics that cover this already if you want to google it. Better than I could explain probably.


But regardless, client/peer-to-peer networking is innately vulnerable to hacking, unless you specifically designate one player as the "host" to do the validity checks of actions. And with that, if the host is also a hacker, interesting stuff can occur. The only way to make sure that things are server-sided is to mirror the game state on the dedicated server and/or gamesparks and validate any user input. In that way, it shouldn't matter if a hacker sends an erroneous request to the server as you can simply error-out any request you don't need/use, or validate that the action coming in is "reasonable".


1 person likes this

Okay, that makes sense.


The situation where the host is a hacker would for sure be an issue in the client acting as server situation. They could potentially send modify the contents of a request. 


So, back to the original question of having "admin" users. Would the best approach be to have the dedicated server authenticate/login with GSparks as a "special" user which all designated servers will "login" as (can multiple devices be logged in as same user?) and when certain requests are made (such as updating player statistics) we check that the correct user is making the request.


Better way possibly?

It is possible to add privateData to a player on gamesparks that will designate their 'permissions', if you will. And in cloud-code, you can do a: 

require("IS_ADMIN");

 where IS_ADMIN checks if the privateData.userLevel >= some designated number for admin, if not, quits out without doing any processing (setScriptError).

Sorry, misunderstood again lol. There are credentials you can use that restrict actions. You can create a Credential just for the client, and use another credential (ie server) for the administration requests. In the credentials section, you can specifically designate which requests to enable/disable. So while the server will have full access based on one credential, the client connecting to gamesparks might use a different credential to connect that is minimal permissions.


1 person likes this

Perfect.


You rock, Christopher Bonnell!

Thank you very much.

Login to post a comment