Maybe future problems

[Jackolantern]

What causes a page reload? If the user is walking animated on the map and can move at will, it is tough to sync it to the server using AJAX without burning tons of bandwidth and causing a lot of server load. However, if the page only reloads when the user touches a teleportation portal, the location of that portal could be used to set the player on the next page.

[Jackolantern]

Server-side confirmation is the only real security. That has historically been the problem with AJAX syncing since it is too slow to sync in the same way that sockets can. But you can get clever and try to ensure that the server can at least confirm the main points of attack. For example, when the player moves towards a door, send a single message to the server that they are in that area. When the server gets a response that the door has been opened, the server will know there is only one door the player could possibly have opened. If it is any other door, simply ignore it or have a back-up response such as teleporting the player back to the center of the map.

[Jackolantern]

You could fall back to AJAX, but the latency and bandwidth would go through the roof. You would also lose bidirectional communication (AJAX is client-sent only under normal circumstances). A better fallback strategy would be to use something like Socket.io that falls back automatically, first to Flash, and then to Comet techniques so that you can maintain bidirectional communication.

The idea isn't that websockets are more secure, per se. A plethora of tools exist to send whatever data you want to any server. What makes websockets preferable for animated browser-based online games is that they are blazing fast and two-way. They are fast enough to keep the client and the server synced (and are bidirectional, which is required for good syncing), which allows you to keep the real game logic on the server and have the client simply send commands and display output.

Websockets don't prevent things like Tamper Data. They just enable the client-server model that can best deal with tools like that.

[Jackolantern]

Server-side validation is the only way. There is nothing that can be done on the client to make it trust-worthy, thus you can never trust it.

[Jackolantern]

The state of the game must be verifiable on the server. That means the player's current location, stats, combat, inventory, etc. all must be on the server. The client should have as little game state as possible on it. How that is actually implemented is going to vary a lot game-to-game.

[Jackolantern]

No, nothing on the client can be hidden. If the data is sha1 hashed on the server and then sent to the client and the client only deals with the hashed data, it will only be a matter of making a table relating what those hashes represent (look at what was sent, observe how the game reacts, etc.). If the data is hashed on the client side before being sent to the server, then the user can simply debug your scripts and get the values before they are hashed. Then they can alter the hashed value on the client by feeding whatever value they want into the hash algorithm.

The client is completely transparent, which is the way it really has to be. We don't want anything hidden going on in our web browsers, because those would lead to massive security vulnerabilities. To prevent cheating, the only way is to make sure everything can be validated by the server, since it is, and always will be the only semi-trusted part of the system.

[hallsofvallhalla]

Sorry if I missed half the conversation but I did server side checks like

Lets say a player is at R4:C4 and he does a url injection of R20:C20. On the server it gets the players current location from the DB and then checks where he wants to go.

3:3|3:4|3:5
4:3|4:4|4:5
5:3|5:4|5:5

at 4:4 you can do a check if current R = move R is greater than 1 then CHEATER!!!

and do that for C and R and other things.

soooo

Code: Select all

$localR = $Playerinfo3['mapr'] - $_GET['mapr']
if(($localR > 1 || $localR < -1)
{
echo "Cheater!!";
}

psudeo code but you get the drift

[Jackolantern]

Hmm I will definetly have to do checks server side that the information passed is a valid one I was hoping for a better way of doing it but this works..but I may still send a hashed number with it while the hash can still be seen in the js code at least it's not a single number an cant easily be edited...

You can do that if you like, but just remember that you can't trust the hashing even 1%. If you do, it will be doing you more harm than good. There are some hashing algorithms out there for client-side JS, but they will only stop non-programmers who don't know to just run the debugger and get the value before you hash it.