External Dedicated Server and Writes to Player Data
D
Derek Fletcher
started a topic
almost 6 years ago
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
C
Customer Support
said
almost 6 years ago
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.
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
D
Derek Fletcher
said
almost 6 years ago
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?
C
Christopher Bonnell
said
almost 6 years ago
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.
D
Derek Fletcher
said
almost 6 years ago
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.
C
Christopher Bonnell
said
almost 6 years ago
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
D
Derek Fletcher
said
almost 6 years ago
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?
C
Christopher Bonnell
said
almost 6 years ago
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).
C
Christopher Bonnell
said
almost 6 years ago
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.
Derek Fletcher
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!
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
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstCustomer Support
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
Derek Fletcher
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?
Christopher Bonnell
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.
Derek Fletcher
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.
Christopher Bonnell
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
Derek Fletcher
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?
Christopher Bonnell
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:
where IS_ADMIN checks if the privateData.userLevel >= some designated number for admin, if not, quits out without doing any processing (setScriptError).
Christopher Bonnell
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
Derek Fletcher
Perfect.
You rock, Christopher Bonnell!
Thank you very much.
-
Documentation Notes
-
Design issues with user events
-
Using NoSQL
-
Runtime Collections vs Metadata Collections
-
Anonymous authentication from browser app
-
Modules
-
Movement With Unity
-
Problem with url parameters for downloadables
-
Querying NoSql GameSparks database
-
Challenge accesType
See all 2487 topics