Forum ‹ BigDB ‹ Need for server functions for added security?

[kikurt18]

Hi. I'm creating a game the will consist of a table for puzzles. I'll have a new puzzle everyday. I wish to save the state of a user's current puzzle in the player object. I also want to use Player Vault so the user can buy solutions to clues in the puzzle. This is pretty straight-forward (in concept, anyway). I am using a Flash obfuscation program already, but now want to take the next step and integrate with the Player.IO APIs.

So it looks like it's best to make generic named client function calls to the server and have the #C code actually do the dirty work...making Flash as dumb a client as possible. So if I set up the DEV server example that was part of the Player.IO development download, I should be able to get things set up? Will this allow me to use a Public AND a Dev DB connection or do I need to upgrade my price package to "Plus" first?

[Henrik]

Server-side code does not use a named connection, it just has full access to everything since it's trusted code.

You can restrict your public connection to read-only so that your Flash client can only read from BigDB, and then do all writes to BigDB through server-side code, and you don't need to upgrade to a paid plan to get access to all of that.

However, PayVault is a paid plan only feature, so you will need to upgrade if you want to use that. But you can get pretty far in your development before actually integrating with PayVault, you should be able to figure out and implement all of your server-side code before that.

[kikurt18]

Thanks!

So saving data to Player.IO player object would need to be server-side as well?

[Henrik]

So saving data to Player.IO player object would need to be server-side as well?

If you allow changes to BigDB from client-side, then a player can create a hacked client and change his BigDB data in any way.

If that's bad for your game, then yes, you should disallow changes to BigDB from client-side, and only do changes from server-side code.

When I read your description however, it sounds like you could be fine with client-side BigDB writes. If you purchase help for the puzzle, and put that help in server-side code so that it will change a player's puzzle to be a little bit more solved, then it doesn't matter if a player can modify his BigDB data in any way, since he still would have to figure out how to solve the puzzle, as long as there is no property on the BigDB object that indicates how far solved it is.

[kikurt18]

That makes sense. The only other issue I can think of is limiting the number of requests from a hacked client to the server. How would you suggest handling that? For example, if I had a server function for saveGame() that is called from the client, how would I limit the number of times this could be called? Do you have any examples of this?