How to protect GAE server-side calculation logic?

Question

Let\'s say I have 100 fields in the html form. When all fields are filled in, some score is calculated and shown to the user (let\'s say the score value is from 0 to 3000).

Answer 1

There is not a single solution to this. You may attempt make it hard for the user to hack it and to do so undetected and apply the coercive measures possible.

• use an "enabler" cookie (or set a session flag) when the user displays the form and check for this specific cookie or flag before you hand the response. Clear the enabler once a response has been provided and don't allow submissions for those who already submitted
• randomize field names and check at the server side if the fields have the proper random names
• use a cookie to check if the user already submitted the form (it's easy to defeat)
• check for user agent against popular HTTP libraries (and don't allow people to submit forms with them)
• monitor if the same IP makes lots of submissions - imprecise, but may indicate something fishy

Those are the first ideas that come to my mind. There will most likely be other insightful comments with others.

Answer 2

For the client:

1. Send the data of the fields to the server and request for score calculations.
2. Put a constraint on your client so that it would wait for the server to finish replying the request sent on step #1 before sending a new one.
3. When the response from the server came back, check the values on the fields, if there is any change compared to the last time you were on step #1, re-do the step #1. If not, monitor the fields and go to step #1 when you detect any changes.

Now for the server:

1. When a request for recalculation come, calculate the new score, but then add an artificial latency before sending the result of the calculation back to the client. (e.g. sleep for 1000 ms before sending a reply back to the client)

With this strategy, you put a maximum rate for the user to 'play' with the values, without the need to have sessions and without the need to have a time-difference check for every incoming requests.

It would be even better if you send the result back to the client asynchronously, perhaps using the Channel API, and put the sleep into a TaskQueue worker instead. That way, the app engine scheduler would not think that your app need to spawn lots of instances due to the high latency exhibited by your request handlers.