@bkbCodes I'm not sure I understand what this is doing. Could you explain more how this helps prevent the exploits so as I read through the code it makes more sense?

@webdevcody @scape76 sure, here you go.
Starting step is when user completed race and is about to submit it.

Prior to this we directly post the details of race, like, cpm, accuracy, time taken etc. This allowed the exploit of re-sending the same request with updated value such as 10000cpm, 100 accuracy, and to make it work better exploiters also used the newly generated raceID. Since, all details are now legitimate this got accepted, marking the completion of exploit.

Now, instead of submitting it directly we do following:

1. Get a signature token from DB (unique signature token), used for generating a hash of the race details.
2. After getting the token, stringfy the race results and create it's hash.
3. And now we send race result along with its hash.

Now at server side:

1. We receive the race result with the hash.
2. Now, server gets the signature token of the user from DB.
3. We stringfy the received data and create its hash.
4. Now, we compare both hashes, if equal, then, all is good we proceed forward, else, data is tampered so ignore the request.

This is main working.
To make it more robust client will get a token as well as a random number that needs to be add to data before hashing to make it difficult to break. And this random number is stored in DB and client can only read it and server can read it and update it. This part was done to avoid replay attack, say I got an impressive race with 800cpm and 100% accuracy, I can resend this multiple times to boost my overall stats, as hash value will be same if no randomness was present.

@scape76 this is the reason I used getUserTokenAndStamp()