question

Ben avatar image
Ben asked

Can the API Permission Policy be used to restrict specific CloudScript methods?

In my project, there are some methods in CloudScript that should be callable from the client, and some that should only ever be called by gameservers or administrators.

For example, a client might call "collectAchievmentAward()" to collect some rewards for an achievement they recently completed. And an administrator might use a scheduled task to call "deleteOldPlayerAccounts()" to automatically use the Admin API to remove unused player accounts. (These aren't the best examples, but I hope my point makes sense anyway)

From what I can tell, the client can invoke any CloudScript method using an ExecuteCloudScriptRequest, which seems like an issue if I have some methods that the client shouldn't be able to use.

CloudScript
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
brendan avatar image
brendan answered

The permission policy applies only to the Client API at the moment, but more to the point, it's a global policy - if Client/UpdateUserData is turned off for your title, it's turned off for everyone.

To do what you describe, you should use something akin to the Secret Key for your game, so that your game server/admin calls include that as an argument, and your script checks that the key is present and correct.

11 comments
10 |1200

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Ben avatar image Ben commented ·

That makes sense, thank you!

0 Likes 0 ·
kurt avatar image kurt commented ·

I can see how this would work for handlers called by trusted game servers, but what about handlers triggered by PlayStream events? Seems like spoofing a context object would be easy enough. Is there a mechanism for including a custom key in built-in events like player_created?

0 Likes 0 ·
brendan avatar image brendan kurt commented ·

It's not technically possible for someone to spoof any of our built-in events. If you're using a custom event to trigger a Cloud Script through PlayStream, then yes, a hacker could potentially spoof that. If the WritePlayerEvent call is being made by the client, the hacker's call to it would look exactly the same, as far as the service is concerned. You'd need to do some additional checking in the Cloud Script logic, to try to prevent misuse.

0 Likes 0 ·
1807605288 avatar image 1807605288 ♦ kurt commented ·

For this case, it's entirely custom. You just want to basically have a super-secure "password" that allows certain Cloud Script functions to be unlocked.

I would advise AGAINST using your title secret key explicitly, since it's not actually the same mechanism, and separate keys helps reduce the impact if one or the other gets exposed.

Answering your questions specifically:
No, there's no built in mechanism for this.
Yes, it works ideally for Game Servers.
You can provide a json context object to every Game Manager based Action that calls Cloud Script, and the key can be provided securely there.
As far as I remember without going through and checking everything myself, I think you can provide the key safely in every circumstance that isn't from the client.

If there's any context implied by your question that I missed, please let me know.

0 Likes 0 ·
kurt avatar image kurt 1807605288 ♦ commented ·

Thanks for the quick responses, guys. I'm not 100% on Paul's response about Game Manager, so here's my specific concern for clarification.

I have 3 handler functions as follows:

Function A - called by client. I'll assume no security here and validate all calls by cross-checking user data or something similar.

Function B - called by game server. I'll require an extra, unrelated secret key as an argument in addition to any other logical validation.

Function C - triggered by PlayFab player_created PlayStream event. As far as I can tell, since I'm not explicitly triggering the event and it's generated by client action, there's no way to guard against illegitimate use of this function via secret key. I can only limit its impact and/or validate calls against existing data.

Is my understanding correct?

0 Likes 0 ·
Show more comments
se avatar image se commented ·

Sorry for opening an old question, but is the approach described here still the desired way to achieve this? Or is there a new way now?

I would imagine a "source" parameter on context could be a nice way to fix this problem in the future. This way we don't have to use from the limited api-calls we have to verify the source of the trigger, specially from scheduled tasks or similar which has a limit of 5 api-calls as far as I understand.

0 Likes 0 ·

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.