I want to measure the time it takes for a user to complete a task (answer a quiz). I want to measure it accurately, without the network lag. Meaning, if I measure on the server side the time between 2 requests, it won't be the real time it took the user, because the network time is factored in.
But on the other hand, if I measure in javascript and post the timestamps to the server, the user will be able to see the code, and cheat by sending false timestamps, no?
How can I get the timestamps in javascript and make sure the user doesn't fake it?
Generally in client side code, any question that starts off with "How to securely..." is answered with "Not possible". Nothing, not even putting variables in a closure (because I, the evil cheating user could just change the code on my end and send it back to you).
This is the kind of validation that should be performed server side, even with the disadvantage of network latency.
The trick here would be to measure the time using JavaScript, but also keep track of it using server-side code. That way, you can rely on the timestamps received by the client as long as you enforce a maximum difference between calculated times. I'd say a few seconds should be good enough. However, by doing so, you are creating an additional vector for failure.
Edit: A user could potentially tweak his or her time in their favor by up to the maximum enforced difference if they are able to take advantage of the (lack of) network lag.
I faced same problem while designing an online examination portal for my project.
I went for a hybrid approach.
Get time from server as user loads the page, and starts timer based on javascript. Record the start time in your database.
Let the timer run on client side for some time, say 30 seconds.
Refresh timer by making a AJAX call to server for timer reset as per the time that has passed already.
NOTE: try to use external javascript and obfuscate the code of timer to make guessing difficult.
This way you may not prevent user completely from modifying timer, but you can limit max possible error to 30s.
Related
I'm working on a web app which must measure the time user needs to do something. I can't simply use javascript time object, because the user may change system time to cheat and fool the app. I'd need some way to prevent this.
I would make the web app send heartbeats or any other form of signals back to the server side. Then you can construct some metrics like duration = end - start
Accounting for the round trip client-server communication, this isn't suitable for ms resolution measurements, obviously.
Note : It's not a good idea to just read the time from a "trusted" web service into your client side app, you can't really guarantee the app wouldn't temper with it. (One of cardinal rules in client side dealings, is to not trust its input, e.g. for validation, you still need server-side validation on top). However if you just send signals to the server, log its timestamp using the server's clock, you are a lot safer.
Calculate time on the server side.
The client user cannot futz with that (at least they should not be able to)
Then you have to do it on the server side. Everything that happens on the client is manipulable.
One way would be to do ajax calls and measure the time in php or other server sided scripts.
A lot of this depends upon what time measurement accuracy you need.
If you are measuring long times (a minute or longer) and just need accuracy to within a minute, then using an ajax call to fetch a remote server time is clearly a more foolproof way than any client-side clock measurements.
If you are trying to measure shorter times in under a minute, then you will need to use the local clock to achieve any sort of accuracy. For that, you can check if the local computer's clock has been messed with using the following type algorithm:
Send a remote request to a server to get the current time. This could be either a publicly available time resource or your own server.
Get the current time on the local computer.
Calculate the offset between those two times. What you are looking for is that there is no significant change in the offset.
Using local computer time, mark the start of the local operation
User does their operation.
Get current time on the local computer to mark the end of the local operation
Get remote time again.
Get the current time on the local computer
Calculate the offset between local and server time. Allowing for a small difference in the amount of time it took to retrieve the remote time, see if the difference is relatively the same as the previously calculated difference. If this difference is not the same, then the local clock has been messed with.
Note, because you can't instantaneously get the remote time (there is always an indeterminate delay time in retrieving it), there is an inherent inaccuracy here of a few seconds in verifying that the local clock has not been messed with. The inaccuracy is not in measuring the local operation, just in verifying that the local clock hasn't been messed with.
So ... this technique works best for detecting clock manipulations that are more than a few seconds, not smaller manipulations.
I have just stepped into the world of Web Development, and I am developing a small browser game that simply allows connected users to take control of an object (a triangle currently!), and simply move around the screen area.
Currently, I store the clients co-ordinate position in a MySQL database, and update that position using AJAX, roughly 30 times per second.
Other clients positions are also polled roughly 30 times per second.
My problem however, is that this seems to be causing an hour long IP lockout for the client, which I assume is automatically occurring on my Host's end. Would this perhaps be a normal default precautionary action? I was under the impression that 30 AJAX polls in a second was not a particularly stressful amount, however as I mentioned this is a new field for me. I'm fearful I've created some miniscule DOS attack!
If so, I would be grateful if someone with experience in this matter could point me to a more efficient method of handling the kind of interactivity I have described. This is all leading up to a six-month project I will be working on alone for my final year University project, so I'm more than happy to put the extra hours in to learn a better solution.
What you should do is known as "hybrid-polling". Basically you have a long running method server side which is running an "infinite" loop which runs once every 33ms (30 times per second). This loop will shoot data out to a part of your front end if the data has changed. When the data gets to be too large in the buffer for the method to handle, the method exits. The whole time your client is polling to see if new data was written. If the method exits, the client must restart the method. This is a hybrid approach, where the client polling is only checking client side data, except when the method exits, in which case the client must poll again to restart the server method, which then runs once every 33ms and pushes data out to the client.
Look up Comet (compatible with older browsers but not as efficient as possible), BOSH, or Web Sockets (ideal but not compatible with older browsers) for other approaches.
If I make a live countdown clock like ebay, how do I do this with django and sql? I'm assuming running a function in django or in sql over and over every second to check the time would be horribly inefficient.
Is this even a plausible strategy?
Or is this the way they do it:
When a page loads, it takes the end datetime from the server and runs a javascript countdown clock against it on the user machine?
If so, how do you do the countdown clock with javascript? And how would I be able to delete/move data once the time limit is over without a user page load? Or is it absolutely necessary for the user to load the page to check the time limit to create an efficient countdown clock?
I don't think this question has anything to do with SQL, really--except that you might retrieve an expiration time from SQL. What you really care about is just how to display the timeout real-time in the browser, right?
Obviously the easiest way is just to send a "seconds remaining" counter to the page, either on the initial load, or as part of an AJAX request, then use Javascript to display the timer, and update it every second with the current value. I would opt for using a "seconds remaining" counter rather than an "end datetime", because you can't trust a browser's clock to be set correctly--but you probably can trust it to count down seconds correctly.
If you don't trust Javascript, or the client's clock, to be accurate, you could periodically re-send the current "seconds remaining" value to the browser via AJAX. I wouldn't do this every second, maybe every 15 or 60 seconds at most.
As for deleting/moving data when the clock expires, you'll need to do all of that in Javascript.
I'm not 100% sure I answered all of your questions, but your questions seem a bit scattered anyway. If you need more clarification on the theory of operation, please ask.
I have also encountered the same problem a while ago.
First of all your problem is not related neither django nor sql. It is a general concept and it is not very easy to implement because of overhead in server.
One solution come into my mind is keeping start time of the process in the database.
When someone request you to see remaingn time, read it from database, subtract the current time and server that time and in your browser initialize your javascript function with that value and countdown like 15 sec. After that do the same operation with AJAX without waiting user's request.
However, there would be other implementations depending your application. If you explain your application in detail there could be other solutions.
For example, if you implement a questionnaire with limited time, then for every answer submit, you should pass the calculated javascript value for that second.
In other words, what technology would take care of doing the time tracking? Would it be the JavaScript? I don't see being able to keep track of such things with PHP.
Here's what I need to accomplish:
I need to have a long form spanning many web page reloads because it is pretty much an online test where each page load displays a new question. However, the entire form, which constitutes one test has a time limit. When the time expires if the user in question has not completed the test then he/she cannot submit a partially completed test nor attempt to do the entire test all over again within the same day (either calendar date or with 12/24 hours in between.) The user may, however, comeback the next day and attempt to finish the entire test again within the allotted time. I know I have added a lot of details and I did this just to show context, nevertheless, the main difficulty for me would be in how accomplish the time expiry feature. That is, somehow, within a series of pages that make up a form representing an online test I want to track the time starting from the first question (one page load) and upon time expiry for the test to be disabled.
Has anyone ever done this? Would anyone have any tips for me on how to accomplish this?
Any advice I can get would totally be appreciated in advance.
If you do track time on client-side - always validate it on the server-side.
Never trust the client, by itself, to validate the time. As mentioned in the comments, client-side time validation is only good for cosmetic features, never for actual validation.
The easiest way to accomplish this is to add a unique token to the form (which is not spoofable) on first navigation. Cookies, or any other sort of session management technique you get from your framework will suffice.
On form submission you can first validate this on client side and return an error if time has passed, even before actually sending the form. If successful, submit the form, and make sure you validate the token upon processing on the server.
There are two ways you could measure the "time they spent" on the form.
When the first page of the form is severed, in the PHP create a session variable containing the date. When they finish the form, you subtract the current date form the beginning date. This gives you the total time it took from when the form was served and finished. However, this is not 100% accurate as there could downtime for other reasons such as slow internet.
You could have JavaScript record the time on that page (I answered how to do that here: here) Using AJAX, this time could be sent that way or by using GET posts. The time would then be kept by PHP somehow and added up in the end.
Hope this helps! Just ask if you want an example.
In the most general terms, you'll need to set up a session on the server side to track each user and test. When the user begins the test, you stamp a variable (server side) with the test start time. As the user progresses through the test and requests additional pages, check whether the difference between the current time and that variable have exceeded the time allowed for the test. If the test has expired, instead of delivering the next test page, you can close up the test and deliver a "time's up" page to the user.
I don't know what server-side environment you're using, but it almost certainly has some sort of session management framework available. To reliably control the testing environment, you have to manage this from the server side.
It's a simple case of a javascript that continuously asks "are there yet?" Like a four year old on a car drive.. But, much like parents, if you do this too often or, with too many kids at once, the server will buckle under pressure..
How do you solve the issue of having a webpage that looks for new content in the order of every 5 seconds and that allows for a larger number of visitors?
stackoverflow does it some way, don't know how though.
The more standard way would indeed be the javascript that looks for new content every few seconds.
A more advanced way would use a push-like technique, by using Comet techniques (long-polling and such). There's a lot of interesting stuff under that link.
I'm still waiting for a good opportunity to use it myself...
Oh, and here's a link from stackoverflow about it:
Is there some way to PUSH data from web server to browser?
In Java I used Ajax library (DWR) using Comet technology - I think you should search for library in PHP using it.
The idea is that server is sending one very long Http response and when it has something to send to the client it ends it and send new response with updated data.
Using it client doens't have to ping server every x seconds to get new data - I think it could help you.
You could make the poll time variable depending on the number of clients. Using your metaphor, the kid asks "Are we there yet?" and the driver responds "No, but maybe in an hour". Thankfully, Javascript isn't a stubborn kid so you can be sure he won't bug you until then.
You could consider polling every 5 seconds to start with, but after a while start to increase the poll interval time - perhaps up to some upper limit (1 minute, 5 minute - whatever seems optimal for your usage). The increase doesn't have to be linear.
A more sophisticated spin (which could incorporate monzee's suggestion to vary by number of clients), would be to allow the server to dictate the interval before next poll. The server could then increase the intervale over time, and you can even change the algorithm on the fly, or in response to network load.
You could take a look at the 'Twisted' framework in python. It's event-driven network programming framework that might satisfy what you are looking for. It can be used to push messages from the server.
Perhaps you can send a query to a real simple script, that doesn't need to make a real db-query, but only uses a simple timestamp to tell if there is anything new.
And then, if the answer is true, you can do a real query, where the server has to do real work !-)
I would have a single instance calling the DB and if a newer timestamp exists, put that new timestamp in a application variable. Then let all sessions check against that application variable. Or something like that. That way only one innstance are calling the sql-server and the number of clients does'nt matter.
I havent tried this and its just the first idéa on the top of the head but I think that cashe the timestamp and let the clients check the cashe is a way to do it, and how to implement the cashe (sql-server-cashe, application variable and so on) I dont know whats best.
Regarding how SO does it, note that it doesn't check for new answers continuously, only when you're typing into the "Your Answer" box.
The key then, is to first do a computationally cheap operation to weed out common "no update needed" cases (e.g., entering a new answer or checking a timestamp) before initiating a more expensive process to actually retrieve any changes.
Alternately, depending on your application, you may be able to resolve this by optimizing your change-publishing mechanism. For example, perhaps it might be feasible for changes (or summaries of them) to be put onto an RSS feed and have clients watch the feed instead of the real application. We can assume that this would be fairly efficient, as it's exactly the sort of thing RSS is designed and optimized for, plus it would have the additional benefit of making your application much more interoperable with the rest of the world at little or no cost to you.
I believe the approach shd be based on a combination of server-side sockets and client-side ajax/comet. Like:
Assume a chat application with several logged on users, and that each of them is listening via a slow-load AJAX call to the server-side listener script.
Whatever browser gets the just-entered data submits it to the server with an ajax call to a writer script. That server updates the database (or storage system) and posts a sockets write to noted listener script. The latter then gets the fresh data and posts it back to the client browser.
Now I haven't yet written this, and right now I dunno whether/how the browser limit of two concurrent connections screws up the above logic.
Will appreciate hearing fm anyone with thoughts here.
AS