so it appears that the expected way that a leaderboard gets 'pinged' with new data is via linked events (via a runningTotal tied to the individual event attributes)
Deep down in my cloud-code stack, I determine that a win or loss or other player element has changed, warranting a change and then I use a couple of "sendRequestAs" to ping the leaderboard (using a custom LogEvent) for both the winner and loser.
Works great.
Except now I can't seem to figure out how to lock down that custom LogEvent so that it can't be called 'from the outside'. If I don't, players could cheat the leaderboard and win all the great prizes.
Even if I added some special cloudcode to this logEvent (ostensibly to to check if special secret code is included), I assume the leaderboard will still receive the updated event data regardless....
What is the proper way to secure events that impact leaderboards so that they cannot be sent from the client?
Best Answer
T
Tech Support
said
over 2 years ago
We can achieve this through the use of a credentials, this is within the Integrations page.
The default credential you connect with is "device", if you edit this credential you can lock down which api calls the client will be able to call. You can do this on an api call level, and also on individual requests.
If the request is turn off in the credential, if a client attempts to call the api they will get a "Request not authorized" message.
This restriction is only for api calls being sent into the platform, if does not restrict your ability to use cloud code send or execute requests.
One thing to note with SendRequestAs, we will be deprecating this method shortly in favour of the following syntax.
var request = new SparkRequests.LogEventRequest()
request.eventKey = "MYSHORTCODE"
request.score = 123
var response = request.Send()
The benefit of this approach is that you get full autocomplete in the editor.
You should also probably be aware that SendRequestAs(), request.Send() and request.SendAs() will not run any cloud code associated with the request.
If you want the code for the event to run when you do this, you need to use request.Execute() or request.ExecuteAs()
We can achieve this through the use of a credentials, this is within the Integrations page.
The default credential you connect with is "device", if you edit this credential you can lock down which api calls the client will be able to call. You can do this on an api call level, and also on individual requests.
If the request is turn off in the credential, if a client attempts to call the api they will get a "Request not authorized" message.
This restriction is only for api calls being sent into the platform, if does not restrict your ability to use cloud code send or execute requests.
One thing to note with SendRequestAs, we will be deprecating this method shortly in favour of the following syntax.
var request = new SparkRequests.LogEventRequest()
request.eventKey = "MYSHORTCODE"
request.score = 123
var response = request.Send()
The benefit of this approach is that you get full autocomplete in the editor.
You should also probably be aware that SendRequestAs(), request.Send() and request.SendAs() will not run any cloud code associated with the request.
If you want the code for the event to run when you do this, you need to use request.Execute() or request.ExecuteAs()
Hopefully that helps
J
Jeff Amiel
said
over 2 years ago
it does help - thanks much!
J
Jeff Amiel
said
over 2 years ago
Silly question - we manage most aspects of our game config via the RESTful API.
Currently the device credentials looks like this below. Can I assume that an empty ~requests[] array designates that ALL requests are authorized - and the minute I add an entry, I must add ALL the events that are authorized? - maintaining that list every time I add a new custom LogEvent?
Apologies for the delayed response. To answer your question, no you won't have to maintain that list. If you look at the LogEventRequest tab in your credential you'll notice that "LogEventRequest" is ticked, when this is ticket it covers all of your LogEventRequests, even new ones that you create in the future. If you untick that box you can specify which you would like active or not within that credential. If you have any further questions just let me know.
Thanks,
Liam
J
Jeff Amiel
said
over 2 years ago
Liam,
I think you are missing my question
we manage most aspects of our game config via the RESTful API. Can I assume that an empty ~requests[] array designates that ALL requests are authorized - and the minute I add an entry, I must add ALL the events that are authorized? - maintaining that list every time I add a new custom LogEvent?
Customer Support
said
over 2 years ago
Hi Jeff,
The empty request array essentially sets the credential to its default state which has every request authorized (apart from admin requests). So every system Request is on, every LogEventRequest is on and every LogChallengeEventRequest is on.
//ALL system Requests, LogEventRequests & LogChallengeEventRequests authorized.
"~requests": []
//Only LogEventRequests & LogChallengeEventRequests authorized
"~requests": ["LogChallengeEventRequest","LogEventRequest"]
//Only authorize certain system events and ALL LogEventRequests & LogChallengeEventRequests
"~requests": ["AuthenticationRequest","DeviceAuthenticationRequest","LogChallengeEventRequest","LogEventRequest"]
Having ["LogChallengeEventRequest","LogEventRequest"] on will cover all of your custom events so you won't have to maintain a list. Hopefully that should clear things up for you. If you have any further questions please don't hesitate to let me know.
Jeff Amiel
so it appears that the expected way that a leaderboard gets 'pinged' with new data is via linked events (via a runningTotal tied to the individual event attributes)
Deep down in my cloud-code stack, I determine that a win or loss or other player element has changed, warranting a change and then I use a couple of "sendRequestAs" to ping the leaderboard (using a custom LogEvent) for both the winner and loser.
Works great.
Except now I can't seem to figure out how to lock down that custom LogEvent so that it can't be called 'from the outside'. If I don't, players could cheat the leaderboard and win all the great prizes.
Even if I added some special cloudcode to this logEvent (ostensibly to to check if special secret code is included), I assume the leaderboard will still receive the updated event data regardless....
What is the proper way to secure events that impact leaderboards so that they cannot be sent from the client?
We can achieve this through the use of a credentials, this is within the Integrations page.
The default credential you connect with is "device", if you edit this credential you can lock down which api calls the client will be able to call. You can do this on an api call level, and also on individual requests.
If the request is turn off in the credential, if a client attempts to call the api they will get a "Request not authorized" message.
This restriction is only for api calls being sent into the platform, if does not restrict your ability to use cloud code send or execute requests.
One thing to note with SendRequestAs, we will be deprecating this method shortly in favour of the following syntax.
var request = new SparkRequests.LogEventRequest()
request.eventKey = "MYSHORTCODE"
request.score = 123
var response = request.Send()
The benefit of this approach is that you get full autocomplete in the editor.
You should also probably be aware that SendRequestAs(), request.Send() and request.SendAs() will not run any cloud code associated with the request.
If you want the code for the event to run when you do this, you need to use request.Execute() or request.ExecuteAs()
Hopefully that helps
- Oldest First
- Popular
- Newest First
Sorted by Oldest FirstTech Support
We can achieve this through the use of a credentials, this is within the Integrations page.
The default credential you connect with is "device", if you edit this credential you can lock down which api calls the client will be able to call. You can do this on an api call level, and also on individual requests.
If the request is turn off in the credential, if a client attempts to call the api they will get a "Request not authorized" message.
This restriction is only for api calls being sent into the platform, if does not restrict your ability to use cloud code send or execute requests.
One thing to note with SendRequestAs, we will be deprecating this method shortly in favour of the following syntax.
var request = new SparkRequests.LogEventRequest()
request.eventKey = "MYSHORTCODE"
request.score = 123
var response = request.Send()
The benefit of this approach is that you get full autocomplete in the editor.
You should also probably be aware that SendRequestAs(), request.Send() and request.SendAs() will not run any cloud code associated with the request.
If you want the code for the event to run when you do this, you need to use request.Execute() or request.ExecuteAs()
Hopefully that helps
Jeff Amiel
it does help - thanks much!
Jeff Amiel
Silly question - we manage most aspects of our game config via the RESTful API.
Currently the device credentials looks like this below. Can I assume that an empty ~requests[] array designates that ALL requests are authorized - and the minute I add an entry, I must add ALL the events that are authorized? - maintaining that list every time I add a new custom LogEvent?
{ "@id": "/~credentials/device", "canCallback": null, "canHavePlayer": true, "canListen": true, "description": "System device credential", "name": "device", "secret": "thisismysecrettherearemanylikeit", "system": true, "type": "device", "~requests": [] }
Customer Support
Hi Jeff,
Apologies for the delayed response. To answer your question, no you won't have to maintain that list. If you look at the LogEventRequest tab in your credential you'll notice that "LogEventRequest" is ticked, when this is ticket it covers all of your LogEventRequests, even new ones that you create in the future. If you untick that box you can specify which you would like active or not within that credential. If you have any further questions just let me know.
Thanks,
Liam
Jeff Amiel
Liam,
I think you are missing my question
we manage most aspects of our game config via the RESTful API.
Can I assume that an empty ~requests[] array designates that ALL requests are authorized - and the minute I add an entry, I must add ALL the events that are authorized? - maintaining that list every time I add a new custom LogEvent?
Customer Support
Hi Jeff,
The empty request array essentially sets the credential to its default state which has every request authorized (apart from admin requests). So every system Request is on, every LogEventRequest is on and every LogChallengeEventRequest is on.
Having ["LogChallengeEventRequest","LogEventRequest"] on will cover all of your custom events so you won't have to maintain a list. Hopefully that should clear things up for you. If you have any further questions please don't hesitate to let me know.
Thanks,
Liam
-
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 2371 topics