I'm developing a quiz with stopwatch, to calculate how much time user spent answering the quiz. But it's hackable by the user if the user refresh the browser.
Hmm what should I do? should I save the the counter to localstorage every seconds? and resume?
No, local storage is entirely under the control of the user as well.
You'll need to track the information server-side: Have the server record when user X started task Y, and have the server record when they completed it. Nothing you can do client-side will be resistant to an even modest attempt at bypassing.
Even the server approach can be susceptible to bypassing by bad actors (for instance, I sign up for multiple accounts, get all my answers together, and then sign up "for real" and take the quiz in record time). You'll always be in an arms race (IP checking, etc.), but at least you'll have some small chance by using something somewhat outside the user's control.
Related
I have variable in Javascript which are created by reading a number from HTML, adding a number to it and then returning it to HTML.
I want to make it so that no matter what browser/what user you are, you are seeing the latest version of the variable. Currently, if I refresh the page then the number resets to 0 (the default value). I want it so that if I update the number to 1 when someone else views it from another browser they will also see 1 and not 0.
I've seen that cookies are an option, however I thought cookies were client side only? So that would mean that only I would see the latest version of the variable.
I've seen that sessions are another option, are sessions server side? And would they do the job that I am after?
Is there another way of doing this I haven't considered?
Thanks in advance
I want to make it so that no matter what browser/what user you are, you are seeing the latest version of the variable.
You need to send your updates from the browser to a server, and then have that server relay your updates to all the other clients. There are many choices for how to do this, with various tradeoffs and complexity.
One method is to simply take that number and send it to the server. Then, on next page load, the server injects that new number into the page it outputs (or it serves it up via an API call, over AJAX, via the Fetch API, or server-sent events, WebSocket, etc.). If you do this though, you will need to decide how to handle concurrency. What will happen if two people load the page at the same time?
The general system you're describing is called Operational Transform, and this is a rabbit hole you probably don't want to go down right now. Just understand that there's no magic that synchronizes things across the planet perfectly and at the same time. Your system has to account for inherent delays in some way.
I've seen that cookies are an option, however I thought cookies were client side only?
Yes, cookies are client-side. They're sent to the server with every request, but that's not a useful tool for you, aside from session identification.
I've seen that sessions are another option, are sessions server side?
They can be, but you need to find a way to know what the user is between browsers. Normally, a session ID is stored in cookies.
Here is a new requirement that I need help with. Our users request that 2 minutes before the session timeout, warn them. (i can use a global javascript to check on every page since once a page is loaded, the session reset and by default, another 20 minutes is extended). at the 18th minute, a javascript popup shows up, asking the user "You have two minutes left before being logged off. Do you want to extend the session"?
Up to here, all is fine. But then once they hit "Extend it", then what? I don't want to refresh the page because the data they've already entered will be lost. Is Ajax needed? If so, what is the programmatic way to extend the current session? (not modifying web.config just to be clear)
Also, say they are talking to someone and did not see the javascript confirmation during the 2 minute. Is there anyway to "hold" the session, till the user decides to do something?
Thanks
I was recently working on a similar problem. With ASP.Net every call back to the sever resets the session timeout period. So a Ajax call is going to be your best bet.
As for holding the session, are you actually storing anything in the Session object that needs to be maintained? Or when you say session do you mean the period that the user is authenticated for? If it is truly Session and you are not storing data then it shouldn't matter id it expires. You may want to take a look ar the below link.
Forms authentication timeout vs sessionState timeout
Is it because you have limited space to store session information of a logged in user or security concerns of allowing a user to be logged in for an extended time period, or probably a mix of both?
Is this done at the back-end or front-end?
Assuming it is a back-end requirement, I have seen lot of Javascript codes that creates a widget alerting the end user of a time-out. However I don't see how it can be really coherent with the server other than a guideline that says you haven't performed an Ajax operation for a certain amount of time and hence your session will be timed out without really checking back-end, because if you are checking back-end then you are actually extending you session.
Also in general, what is the criteria that extends the session of a logged in user? Does he have to fire an Ajax request to the back-end (assuming a SPA) or is it enough if he clicks on an input field? If so we do we keep a timer that gets cleared each time this happens? (Again not really coherent with the server but works practically). I know this is a broad question. Any pointers would be helpful.
[PS: If it is more about theory, I could just move to another site in the SO Network? I thought it is a relevant question for beginners.]
This question has cropped up a few times in various guises, but I've not seen an answer that satisfies my requirement or fills me with much confidence. Let me set the scene.
We currently have a web application, which allows users to submit responses to pre-set questions where the data ends up in an SQL Server database, we also have a Windows application that does the same thing but works in an offline capacity; i.e. it connects to the SQL Server, downloads the questions, allows the user to complete them offline and when they next have a network connection they can synchronise the data, uploading it to the SQL Server. Great!
As part of our development strategy, given HTML 5's offline capabilities and local storage,it seems perfectly sensible to attempt to consolidate these products into a single web application. This would mean we're able to work on a single code base, and this would also enable the application to run in a browser on most devices; platform independent.
Looking into this I see a couple of potential problems, I'd really appreciate a steer on these:
Users need the ability to login, in offline and on-line modes. This could mean we download the hash's of the all users usernames and passwords, or just those that have logged in whilst in on-line mode. However, even doing this there needs to be a way to check these and given that the Javascript is readable someone could easily reverse engineer their credentials. Yes you can obfuscate the code but this isn't infallible.
The data that needs to be stored locally could be highly sensitive; contain personal information etc. Therefore this also needs encrypting, at minimum AES 256.
Am I hoping for utopia? Is this something that's just not possible at this time? Do I need to be looking at another solution and dismissing this for the time being?
Any help from you lovely people would be much appreciated.
First the easier question 2: that is perfectly possible. You can generate the key on the device and on sync send it via https to your server which can decrypt the data then.
As for question 1 I'd say an offline login is not really feasible BUT do you actually need one? Once the questionaire is downloaded (which requires online mode, so requiring login is fine) you only need to transmit it on sync, where online is again required and you can ask the user for his login there, too. I'd not recommend to download any sensible user data (e.g. hashes) to the device.
What you can do is to cache the current user only after logging in online. This would mitigate the risk of enumerating the users in your local DB.
You then need to encrypt the user's data on the front-end, I'd go with a library that does the job for you (for example, RxDB). RxDB accepts a password (which you can generate on the fly) and based on it, encrypts your DB data. The user then fills in the form (does whatever he wants) and if all of the sudden the internet is gone, the user is still able to continue his work and that work must be added as pending requests in order to do the sync. (which you already have)
When the internet is restored, you're going to check whether the session has expired for the user and if so, prompt the user to log in again and do the sync if it was the same user. If it's still there, perform the sync.
My advice based on my personal experience for the offline part.
You can create a local variable that allows the user to login once using internet for the first time then he will be able to auto login for several times as much as you decided in the local variable and when the value is 0 he will need an internet again to get another offline access for the same value you decided before.
so, in a small words. offline counter that will need an internet Only after many offline logins (when the counter decrease to 0)
Flowcharts
This question already has answers here:
Unique IPs in a voting system
(7 answers)
Closed 9 years ago.
I'm building a simple web app with an up-vote option. I plan on offering cash rewards for the most up-voted so I want a relatively secure system. I have a couple questions about conception. I know that my post is similar to a few others but none seem to be specific enough to the platform to put my mind at ease.
My web app is utilizing javascript and firebase for loading all of the objects that are being voted on. I'm going to force a user to be logged in and store IP addresses, user IDs etc.
Questions:
Is this fundamentally flawed from the start for using javascript? I see a large potential for writing a script that just changes values and re-votes. (maybe I can verify the front end data is correct and that the user exists with an ajax call?)
With the off-beat chance my app becomes successful Is this going to be too much front end computing?
Edit:
I'm sorry, but I left out the key fact that I do have a larger back end system(WordPress) that handles authentication. The app I'm working on is largely independent from wordpress. I'm simply pulling some user information for filtering purposes. I chose Firebase as a storage solution for its real-time features.
I'm hoping to combat voter fraud with a few methods:
low rewards $100/month given away.
being logged in isn't a compromise, I actually want users to be registered and verified with human eyes to be eligible to vote. Others can witness the contest but cannot vote.
server-side checks. If my app gains popularity I can write scripts to monitor voting patterns for irregularities? if someone is abusing the system, I disable their ability to win.
It is certainly possible to do this securely client-side. However, as noted by others, it does require users to login. If you're already using Firebase, this is actually pretty easy to implement using the FirebaseAuthClient.
You can then couple this with Firebase security rules to enforce that any logged in user can only upvote once. Check out the screencast on the security page for an example!
Your security rules might look like:
{
"rules": {
"users:" {
"$userid": {
"voted_on": {
"$articleid": {
".write": "!data.exists()"
}
}
}
}
}
}
This ensures that you can write any given value to /users/anant/voted_on/article1 exactly once. You can add a .validate rule to ensure that the value is a boolean (or something else).
This is what you should probably do:
1) As soon as user votes, you should make an ajax call to the server and update the flag in the database and disable the voting using javascript.
2) If the user refreshes the page and tries to vote up again, the server would be knowing that the vote has already been made(as it is saved in database) so the voting system will appear disabled on the page.
3) If the user tries to enable the voting using chrome tools or firebug by modifying the source of page, you can create a check at database end by setting the composite key on userID and "vote" flag which would prevent the duplicate votes.
Hope it helps..
There is no way to prevent duplicate votes but forcing users to sign up (maybe with email confirmation) and authenticate (thus, storing votes somewhere in your DB and checking). Other techniques are flawed:
cookies/session storage can be disabled or cleared whenever the user wants.
IP address tracking prevents usage behind NATs, proxies and gateways, since all clients will share the same public address (or a small number of).
Still, a user could register multiple accounts and there is no way to prevent this.
A thing you can do is detecting rapid sequences of vote actions, which could be generated by scripts.
Taking advantage of OAuth authentication, it's highly unlikely that users cannott find a way to login via either FB/Twitter/Google/OpenID.
It is still cheap and fast to vote, and in case the user does not want to login via third party services, you can provide an email fallback.
As everybody pointed out already, you have to rely on you own server.