I am trying to code a multiplayer game demo in javascipt using no libraries. Everything is going pretty good, but in order to get better performance to move forward I am going to have to try minimize the data I sent over my websockets or I won't be able to do much. I have been thinking about the best way to do this. I am using Node.JS + Express + Socket.IO.
At first I was sending the keyboard state of all the keys from each client to the server and quickly narrowed this down to true/false values for only the keys I was using. But now I am thinking that I should really be doing something like assigning decimal literal values (0, 1, 3, 4) to each possible input state that are allowed (possible combinations of inputs) and simply sending that value to the server.
I have more experience in statically typed languages such as C++, Java, etc. so I know how I would do this in those languages. But basically want I want to know is if I have a small number of possible input states. What is the best way to send this data using javascript on both ends. It will be going into a JSON object. Is there anyway for me to send a single byte?
https://gist.github.com/1437195 No idea if this works but that could the most optimized solution. I've never played with byteArray. I have no clue if they play well with socket.io.
Related
I am getting the information from the user. Then I am to sort the information (Alphanumerically), and give it back to the user again, hence not saving it to the database.
I am able to use either JavaScript (you could even count on jQuery), or PHP to do the sorting. Since the data might contain many lines, I am wondering about approaches below for the sorting:
let's say I tokenize all the lines using an array called lines
in JavaScript lines.sort();
in PHP sort($lines);
I am very keen to know if client-side or server-side would be doing this any differently, mainly in terms of speed. Also, if accuracy is important, then would they be any different at all? Please explain why.
1) jQuery sort() is speedy as it has client side load.
2) For server side sorting we need to find from whole data not only from display in current page for pagination.
For Server side sorting is best for:
Large data set
Faster initial page load
Accessibility for those not running javascript
Client side sorting is best for:
Small data set
Faster subsequent page loads
Ability to let the user sort without loading page
That makes difference between server side sorting and client side.
It would depend on the situation. Javascript means client side load. So if the client has a slow system it might take longer. But server side means you would have to get the data into php (either database or by request etc.) and after the sort back to the client.
One other thing to think about is that php is controlled. You can assure the output is the same. In Javascript it should be the same on every system. But different browsers could generate different results on sort.
I'm going to be developing an online arcade for HTML5/Javascript games written in a to-be-released IDE.
The game will use Ajax requests to the server to record scores when people play these games.
I theoretically have complete control over the design of this, including the mechanics of the code that logs the high scores, game code, everything.
I know it's never impossible to hack client side games such as this or spoof high scores, but I want to make it difficult enough so that anyone competent enough wont be bothered enough to do it (wishful thinking).
I've read:
How can you prevent bogus high scores from appearing on a global high score list?
Which is a slightly different question as this is HTML/JS specific.
My initial idea is that the ajax request checks the source of the request is from the correct location, which is a simple and effective block for most hacking attempts.
As the previous answer stated you cannot trust the client, therefore your best bet is to split a game up into levels of some sort and have the server control level progression. If the server is tracking each client and their progression it can limit the range of scores achievable. This makes it more tedious to cheat as the client has to simulate going through each level and indicate achievement within the correct score range.
Each time you serve the page include a randomly generated key and on the server associate the key with the users session.
pass this key around and manipulate it in obscure ways at various points in your game script.
generate a checksum derived from the score and the manipulated key.
send the checksum to the server along with the score
validate the checksum on the server
obfuscate the script
It won't stop a dedicated hacker though.
Here is one way that is both pretty simple (though not trivial) to implement and very hard to hack and not so simple to hack.
On the server side, have list of let's say 1000 items stored in either text file or database.
Each item will be unique GUID or other unique long string, let's call each item key.
Now, when you send AJAX request send one of those keys as well.. it can be random from the list or by incrementing index it doesn't matter.
Now comes the nice part: after one single "use" of each key (meaning the server got request with that key and responded to it), remove the key from the file/database. If the server get request with key that does not exist in the list, of course throw error or return "no hacking" string.
When the list becomes empty, recreate it with fresh unique keys.
This way the first request with the real key should succeed as usual, but if the user will try calling again to the same request exactly, it will fail. Guessing the keys is also very hard assuming those are long random values.
Like any other way, it's flawed due to depending on client side code that can be spoofed by those who know how. But as it's not common, it will be harder for the common folk to find how this works and hack it.
This doesn't work for all games but...
If you log all control input on every frame, and also log the RNG seed at the start of the level, it may be possible to re-run the level by replaying the controller input and get the exact same sequence of events. This can be used to verify that the game was actually played and the score was not just made up. It will be expensive to verify every game, but there are other options, e.g. only verify a game if the score would be in the top 100, or test random games and disable the accounts if verification fails.
Then sit back and watch as the cheaters start using robots to play for them instead, which is even harder to defend against.
Add a md5 hash of the highscore code and compare it on the server. But do not the md5 exactly of the highscore, not on all chars of the highscore only some of the chars, like second to last char. In this case it will be difficult to see what the md5 consists of, when just tracing the ajax calls.
im building a web app in html5.. basically a form with a time counter and questions and answers.
im looking for a way that the user cannot change the score (that is calculated from the time took to answer the question) via browser debugger or etc.
encrypting the raw data sounds like an options.. but when the data is at dom, the user can change it.
i added some "time checking" in server side.. but still i would prefer some client side protection as well.
any suggestions? thanks
I'm no web pro, but I'd say just stick all the validation on the server side. From what I know about people exploiting MMORPGs, there is always a way to access/change client side data.
What you're asking for is impossible. No matter how you implement it, the user can use debugging tools to alter how the code runs in their browser - or, ultimately, just generate the HTTP POST request themselves, independent of your code.
Well, since you're saying you're using html5, why don't you just use the storage support?
e.g:
var store = sessionStorage.question= new Array();
store[0]="10s";
store[1]="5s";
Now just set that programmatically! It will last for the whole session
Put that in a file and import it and the better-than-average user wont know where to look!
You can also check This Link for a more robust solution
As Nick says, a determined user will be able to get round any encryption scheme you use on the client machine. At most you can make it difficult for them to break. You need to do two things, 1) encrypt so as to make tampering difficult and 2) try to detect any tampering that does occur.
I don't know what is available off the shelf for Javascript, if available then use AES for encryption and HMAC to detect tampering. If you have to write your own then use RC4 for encryption (not as strong as AES but much simpler to code) and a checksum to detect tampering.
One thing you can do to make it more difficult for an attacker to find your encryption key and HMAC key is not to store them in one place. Have two arrays such that the real key is array1 XOR array2. That way the actual key is not explicitly in code anywhere.
This is a javascript security question: suppose a page finds out the screen resolution of the computer, such as 1024 x 768, and want to use an AJAX call to log this data into the DB.
Is there a way to actually prevent fake data from being entered into the DB? I think whatever the HTML or Javascript does, the user can reverse engineer the code so that some fake numbers get entered into the DB, or is there a way prevent it from happening totally? (100% secure).
Update: or in a similar situation... if i write a simple javascript game... is there a way for the user to send back the score by AJAX and lie about their score?
If you start with the assumption that the user you are communicating with is malicious, then no; there is nothing you can do to control what data they pass you. Certainly not with 100% certainty - in the worst case, they can use network tools to rewrite or replace any "correct" content with whatever they want.
If you just want to prevent casual maliciousness, you could obfuscate or encrypt your code and/or data. This will not deter a determined attacker.
If you actually trust the real user, but suspect that others might try to impersonate them, you can use other techniques like a dynamic canary: send the user a random number, and if they return that same number to you, you know that it really came from them. (Or you're being hit by a man-in-the-middle attack, but hey; that's what SSL is for.)
It's not possible to stop users from sending any numbers they like back from JavaScript.
I think the best you could do is do some sort of check on the server-side to make sure the numbers sent back look like a realistic resolution.
I'm not sure why someone would spend the time to spoof those numbers in the first place though.
Yes, you are correct. Since you're using client-side code, you have to tell the
user's computer (and thus the user) in one way or another, whatever encryption or obfuscation you're using. There's no way around it.
For the resolution, it would basically be impossible to determine if it's valid resolution. My resolution is usually sent to the server as 5120 x 1600, which seems pretty unrealistic, but it's because the 2 screens are often sent as 1. Otherwise, there is a such a huge variety of possibilities in screen resolutions and screen configurations, you'd probably remove a lot of valid ones, although they might be few.
For the game score, you could do additional checks that make it more complicated to check. Things like sending multiple notices of the score throughout the game and requiring X number to ensure that the score received is valid. (IE, must receive one between 200-300, 400-500, 700-800 and then the final score of 1000.) With the final score, you could also have some kind of encrypted value that can only be used once or that contains some data with a CRC on it. Basically, in the end, require receiving other data than just the score, especially for higher scores.
To attempt an answer by elaborating on comments made by Dok, and yourself, there is a clear distinction between manipulating an application to 'cheat' it out of something, whether it be an online business to get something cheaper or a MMPORG to get more experience, than manipulating it in such a way that it renders the interface incorrectly and diminishes the overall user experience for that particular (hacker?) user.
Your time would be better spent focusing on other aspects of your site. I don't recommend the users of my site manipulate the HTML to make it look funny on their machines, but I'm not going to go all out and obfuscate my server output to stop them from hurting themselves. In your case, range checking against pre-defined safe values, making use of the DB, to ensure the user is viewing with an 'allowed' resolution puts unnecessary burden on your application, and takes time to do.
The objective is to have a form reflect user's defined constraints on a search.
At first, I relied entirely upon server-side scripting to achieve this; recently I tried to shift the functionality to JavaScript.
On the server side, the search parameters are stored in a ColdFusion struct which makes it particularly convenient to have the data JSON'ed and sent to the client.
Then it's just a matter of separately iterating over 'checkable' and text fields to reflect the user's search parameters; jQuery proved to be exceptionally effective in simplifying the workload.
One observable difference lies in performance. The second method appeared to be somewhat slower and didn't work in IE8.
Evidently, the returned JSON'ed struct was seen as an empty object. I'm sure it can be fixed, though before spending any more time with it, I'm curious to hear how others would approach the task. I'd gladly appreciate any suggestions.
--Stan
Why would you want to do this with JavaScript, if you already have a server-side solution that works with all browsers?
I'm curious to hear how others would approach the task.
I would just do it on the server.