I'm designing a client-server system, and i need to understand how to check if the client's data is correct when they send operations and requests. In this particular case, i've got a browser and a javascript client that gets data from longpolling and updates a series of objects wich get binded to html elements, pretty much MVVM.
The steps are something like this:
start polling
get full data
convert the json into a javascript object
update every html object tied to the data
The user can fire an event at any time and works with the latest updated local model.
user fires event
event + full data(all objects converted to json) is sent
Problems are: It's very rough and possibly slow, heavy on the client and the server.
My objectives are to reduce the data transfer to a minimum, and avoid client side corruption/attacks.
How should i go about this?
My objectives are to reduce the data transfer to a minimum
Send only the data that's changed, but the highest cost in AJAX is the request, so unless you are sending a lot of data, it may not make any noticeable difference.
and avoid client side corruption/attacks
Impossible. Your code is running in a browser, the user can do whatever they want.
My objectives are to reduce the data transfer to a minimum
Some things to try:
Reduce the number or frequency of client events that send an update
Send only what data has changed
Compress the data you send
bundle several events into a single request
and avoid client side corruption/attacks.
To avoid attacks, you need to validate all input on the server. You should write your validator without knowledge of the client. You can assume nothing about what combination of data you can get--instead you should assume that someone is hand-crafting requests with a text editor and sending them with CURL.
To avoid corruption (really a "lost update"), use conditional PUTs or POSTs with the if-none-match or if-unmodified-since headers.
Related
I'm using a web server framework which works with only GET requests, at the moment I'm trying to pass a large amount of data, that is the text content in a textarea which comes from user input, into another page which echoes the user's input.
I've attempted Querystrings but I end up receiving the error "Requested URL too long".
Any suggestions as to what method I should use?
If you can only send data encoded in GET requests, then you will have to break up the request and send it in multiple parts.
You could either use Ajax or store the entire set of data in localStorage and fetch each chunk in turn as the page reloads.
One approach would be to make a request to an end point that allocates you a unique ID. Then send a series of requests in the form: ?id=XXX&page=1&data=... before closing it with ?id=XXX&total_pages=27 at which point you assemble the different pieces on the server.
This way lies madness. It would be much better to add POST support to your framework.
Try using Javascript Cookies.
you can store the textarea value there and then read it in another page (or wherever you want).
Here's a tutorial
http://www.w3schools.com/js/js_cookies.asp
If I make an AJAX $.post call (with jQuery) to a php file for updating a certain parameter/number, does it considered bad practise, dangerous or similar?
$.post(file.php, {var:var}, function(data){
// something
}, json);
It would be a single user on a single page updating a number by clicking on an object. For example if user A is updating a certain number by clicking on an object user B should see this update immediately without reloading the page.
It depends on 3 main factors:
How many users will you have at any given time?
How much data is being sent per request on average?
Given 1 and 2, is your sever set up to handle that kind of action?
I have a webapp that's set up to handle up to 10-20k users simultaneously, makes a request each time the user changes a value on their page (could be more than 1 req per second), and it sends roughly 1000 bytes on each request. I get an average of 10ms response time, however that's with node js. Originally I started the project in PHP but it turned out to be too slow for my needs.
I don't think web-sockets is the right tool for what you're doing, since you don't need the server to send to the client, and a constant connection can be much more expensive than sending a request every few seconds.
Just be sure to do lots of testing and then you can make judgements on whether it'll work out or not for your specific needs.
tl;dr - It's not a good idea if your server can't handle it. Otherwise, there's nothing wrong with it.
Another solution could be, to cache user actions in local storage/variables, and send them all at once every 10-15 seconds or so, then clear the cache, when sending was successful.
In this case you should also validate the data in local storage to prevent tampering.
The more I work with AJAX the more I find myself faced with the same problem: I want data on the screen to be as up to date as possible but downloading the same data every second is over kill. The data may change only once every 30 minutes but when it does I would like this to be fed back to the user instantly.
Getting my server side scripts to return data describing the difference between the previous data can be a nice solution but is not always a possibility.
Is there a neat solution to this or is this just something I'm going to have to live with?
Nodejs and Socket.io. It works totally different. In your solution each opened window sends a request to the server, and as a result there is a very huge amount of useless request. Nodejs with Sokcet.io is a real PUSH engine. You can connect users by sockets, and push them notify, that the page should refresh, or updated data itself.
Nodejs and Socket.io links.
you have to query the server every time, that's a given. what you can do is test, in the server, if there is any new data to update and, if not, just return something like 'false', so the callback doesn't do anything and less data is passed around each time.
You're looking for a comet or long-polling technique. Here is a general description with a nice explanation: http://www.ibm.com/developerworks/web/library/wa-reverseajax4/?ca=drs-
Also, the cometd website, which will work with jquery or dojo: http://cometd.org/
I
Another solution is Atmosphere: https://github.com/Atmosphere/atmosphere
Also here: http://jfarcand.wordpress.com/2010/06/15/using-atmospheres-jquery-plug-in-to-build-applicationsupporting-both-websocket-and-comet/
I am testing out some tracking pixel functionality in an ASP.Net 4 MVC architecture.
This article gives a nice way of setting a tracking pixel (image) that you can use to read a visitor's environment parameters and do some logging on the server side before completing the response.
What I would like to do is inject some Javascript, based on the account ID that the pixel came from. In the example above, the ID would be set by setting some query string parameters.
By the looks of that code, it can only be used to log data, as the response type is of type image.
Is it possible to accomplish this using the method shown above? If not, can I get some recommendations/sources on how to accomplish this using Javascript and tying this back into my .Net architecture where based on some logic, I can add some additional Javascript to the response?
If I have no other choice to go the JS route, I'm guessing it would be something along the lines of the Google Analytics tracking script that includes some parameters sent back through JS.
Thanks.
If the client is requesting an image and expecting an image, then that is what you need to return. Look at this type of HTML that would generate an image request:
<img src="test.jpg">
Clearing the client is expecting image bits to come back and anything besides that is going to mess up the display of that image.
If you want to put server-supplied javascript into the page, then simply have the client request some javascript like this:
<script src="test.js"></script>
Your server can then do it's logging upon that request and return whatever javascript it wants to from that request. If you want to return different javascript for every request, then you will need to defeat caching in the browser (there are a number of was to do that) so that the javascript is always requested from the server.
In general, I'm guessing that you don't need to return different javascript for every request. But rather, you can put a common block of javascript in the client page and that javascript can examine the environment and branch based upon what it finds. That's how Google Analytics works. One common piece of javascript is served to the client, that code examines the environment and then makes an ajax request with different parameters set that causes the right information to be recorded on the server.
I wrote an Adobe AIR app that behaves like this:
User logs in and a permanent loop is created using setTimeout. This loop performs an HTTP request, compares a json md5 string that is returned to a global variable. If these two values differ, the dom is updated with new content. When the user performs another action such as sending a reply or deleting a message, a silent update is performed and this "pauses" the loop. It's basically like a simple email client.
The way I'm doing it is unreliable and causes memory leaks. I plan on rewriting it from the ground up, and I don't want to end up in the same boat that I'm in now. If anyone could give me examples of how they would do it or give me any advice, it would be greatly appreciated. Thanks in advance!
You shouldn't poll that often but use a technique known as "long polling" or "COMET". Basically you send a request which will stay open until there's a response due to updated data etc. or a timeout. After some response was received, you immediately send a new request.
This saves lots of bandwidth and server load as it drastically reduces the amount of requests sent.