Hi,

   In short, there's nothing to prevent a user from doing what you
described.  Certainly parameter signing is not a solution, because the
container has no idea of whether a "score" parameter is coming from
the application or the end user (in the case of JavaScript or even
Flash, it's all the end user anyway).  Note that this problem isn't
OpenSocial-specific- it's a real problem on any system where you have
a game that runs client side code that reports a score back to a
central server, since all client side code (even compiled executables)
are vulnerable to being decompiled, hacked, etc. to report an invalid
score.

   Developers typically work around this problem by designing
authoritative game servers which perform validation on the input from
the client.  If the client is reporting invalid moves or scores higher
than would be possible then the server throws out the input.  For
example, if you have a space shooter game where each spaceship is
worth 100 points and you display one spaceship a second, then the
maximum score that you should accept is 100 points / second of game
time.

  Of course you have to make sure that you're not sending too much
data to your server.  In a realtime game, you probably wouldn't be
able to verify whether every bullet fired hits a spaceship or not.
Turn based games are certainly easier to validate, as you can make
sure that each reported move is valid before updating the game state
server-side.

  The addition of server-side support via the REST/RPC client
libraries also helps you move more processing from the client back to
your server.  You may want to look into ways that you can keep
critical game logic from being processed client-side, to avoid
tampering.

Does this help?
~Arne




On Mar 5, 7:41 pm, dburns <drrnb...@gmail.com> wrote:
> Hi all,
>
> I was reading about authentication 
> here:http://wiki.opensocial.org/index.php?title=Introduction_To_Signed_Req....
>
> I understand that the server that receives the request can detect
> tampering during transit.  No problem there.  But what's to stop a
> user with a JavaScript debugger or similar tool from altering data at
> the source?
>
> Consider a simple example, where the application contains this
> JavaScript, which is supposed to set the high score of a game for the
> current user.
>
> function setHighScore(url, score) {
>     var params = {score};
>     params[gadgets.io.RequestParameters.AUTHORIZATION] =
> gadgets.io.AuthorizationType.SIGNED;
>     gadgets.io.makeRequest(url, response, params);
>
> };
>
> What's to stop someone with a debugger to stop on the first line and
> change 'score' from the real value to 1,000,000 or whatever he/she
> chooses?
>
> Thanks,
> DB
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"OpenSocial Application Development" group.
To post to this group, send email to opensocial-api@googlegroups.com
To unsubscribe from this group, send email to 
opensocial-api+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/opensocial-api?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to