I have a site written with PHP: how can I prevent a user from clicking a button multiple times?
For example, I have an upvote button similar to the one on the left of this post. I want non-logged-in users to be able to upvote, but only once. What strategies can i use to prevent the user from clicking it twice?
Simply deactivating the button after first click isnt enough, since they would then be able to visit the page again, or refresh their cache, etc, etc.
The best way for you to do this is to tie the vote to the users IP address in a database.
AND setting a cookie on that computer. That way, you lock it down from two different corners so that you aren't limiting others on the same connection.
You're not really going to be able to fool - proof this successfully without a user login system.
Related
My question is that how to temporally disable a number of buttons/links for user when he clicks one. For example there are 5 buttons: button1, button2.. If he clicks button1 then he can't click any of the buttons again for example 6 hours. Should it be done with php getting user ip, sending it to mysql and "banning" user for 6 hours. Whether clicking the buttons or the url where the buttons are. And after cleaning the specified ip from mysql. The buttons should be banned for the clicked user not for anyone else also refresh or browser restart should grant the option to click any again.
Or should it be done with htaccess somehow.
Extra info: PHP 5.4, mysql.
Site also has a basic login system ( http://blog.geotitles.com/2011/07/php-login-script/ )
But I think it would be easier to do separately.
Have a fool proof way to identify individual users. The only real solution here is to require the user to register and log in.
Store the last time the user did a certain thing in your database.
Check when the last time the user did a certain thing was and do not offer him the button/reject the action should he be doing it again before enough time has passed.
(Optionally: periodically clean out old and unneeded action/timestamps from the database.)
In your users database table, add a last_button_click field.
When a user clicks a button, write a record to the database saying the time they clicked it. When reading the page, check if last_button_click is more than X hours in the past, if so, display the buttons.
If a user shouldn't be able to use duplicate accounts, you'll also want to record his/her IP address in the database and prevent more signups from the same IP address. This isn't foolproof, as users with VPN services like HMA will be able to get around it, but for the majority of users it will work.
You can also look into banning anonymous proxies, VPNs and TOR if needed.
"Banning" a user in a database works fine. When they click the button it should add a ban to the database and when it draws the page again, it should query the database to see if they are banned. If they are, do not show the button, if they are not, show the button.
I have an application and the problem I have is with the back brower buttons, if the user cliks on a back browser, then it would mess things up in the application.
So I want to do either 2 things:
Solution 1: I have found a site where it shows the javascript code for disabling back buttons on all browsers. Obviously you need javascript enabled for this to work but my application won't work very well without javascript anyway so this won't be a problem (I include a warning in each page in my application stating javascript must be enabled in order to use the app)
Solution 2: IF the user does click on the back button at any time, then it will navigate the user to the safety.php page where on this page it will inform the user that they can't use the browser back button, then it will destroy all of the sessions so that the user is logged out. If they want to use the app again then they will have to login again and use the app from the beginning.
My question is that out of both solutions, which one would be better to use? My application is where a teacher creates an online assessment, creating the assessments detials (start time/ duration date etc) and creating the questions and answers for each assesment (could be single or multiple assessments)
Disabling the back button is generally poor usability practice. Your best bet is to manipulate the history object (search pushState if you're not familiar with these methods) so that hitting the back button would return them to a page outside your experience, or however you're accomplishing "Solution 2", but warn them that they are leaving the "logged in" section before they actually leave the page, so that they can choose to stay, using confirm() or a custom pop-up.
use javascript in the first place to prevent adding the location to the history list.
catch the onclick event of the proper link, and use document.location.replace("next_page.html");
so this way, when a user clicks the back button he would leave your site, rather then going back and messing up your app.
also: you can catch the unload event of the page where the user presses back button, so that you can confirm the user for exiting.
I'm currently working on my Referral System, but I have a problem with protecting it of frauds.
Okay, here's how it works for now:
user registers and activate it's account
user now have access to the control panel and there is it's uniqe link in following format: domain.tld/ref/12345
when someone other click to user's link, he or she must to click a specific button to confirm that is not some kind of fraud (like "click here, you'll get $100" or something)
system writes visitor's IP in a database and some data to cookies to prevent re-pressing the button. User now have +1 point.
But, the problem is that visitor can change it's IP, clear cookies and hit button again. It takes a few seconds, and that's not OK, that's cheating.
How to prevent it? Is there some trick to get some unique computer ID or something can't be changed that easy?
Really the only options are to tie the process to something which is not so easily manipulated by the user - super cookies, browser fingerprints, OpenID, Email addresses and telephome numbers (the latter 2 using some sort of validaton step before a vote is counted)
The only way you can be certain a referred party does not reuse a referral code is for the original user to send different one-time-use-only referral URLs to each person. Once the code has been used, it is flagged as such in (or removed entirely from) your database so that it can not be used again.
How you prevent the original user from sending multiple links out to the same person is another matter - and not an easy one to resolve.
Who do you perceive to be the threat?
Although it's certainly not 100% accurate, you can still fingerprint visitors using for example a combination of their ip, browser user agent, and with some javascript you can even go for screen size or installed fonts. Using these pieces of information you can set up a system where you save the fingerprints in datatable and in the same record you store the session id (from the cookie). Now when a new visitor arrives you can test their fingerprint against the db of recent fingerprints with different visitor ids. If you find a large number of matching fingerprints (you define the threshold) with different sessions then you can alert for the possibility of fraud.
Cheers
How about storing the link with with the user when they navigate to the link. then in the database you will have the link and if the users has already been to the link then deny them. Seems like it could work then you wouldn't have to worry about the cookies etc...
I'm trying to use the javascript onbeforeunload event to ask the user if they want to exit the page, but I don't want the event to fire (EDIT: "the event" being the dialog box that pops up asking the user to click ok to leave the site or click cancel to stay on the current page) if the user hits the back button since they will be most likely be staying on my site.
So is there a way to tell if a user has hit the back button using javascript or PHP?
I've gotten a solution using a hidden iframe that only works in IE, but I need something that can work for Firefox, Chrome, and Safari if possible.
EDIT: My IE solution works because when the user hits the back button the iframe is sent back but the parent page remains at the same spot. From this I can tell that the user has indeed hit the back button, so I then use history.back(). This little hack doesn't work in any other browser (to my knowledge), so I'm looking for a cross-browser solution.
tl;dr I'm using window.onbeforeunload to pop up a dialog asking users if they want to leave my site or not. I don't want this to pop up when the user hits the back button. How can I tell that the user has hit the back button in their browser?
Thanks,
Rick
Short answer:
No.
Long answer:
Noooooooooooooooooooooooooooo.
please don't try to keep users on your website unless you have a very good reason to. Saving form fields would be an example of a good use. Checking if they're moving on to another website would be a bad use.
People don't travel from page-to-page as much as they did in the early days of the web. Instead they use google and social networks to find interesting pages, and consume separate distinct pieces of information.
You can't know in advance on which page your user will go when he leaves your page. You can't even get the URLs in its current history.
I see no solution to your problem and I doubt there's one, sorry.
If you don't want anything to happen when the user clicks the back button, then you don't necessarily need to determine if the back button has been hit.
Your goal is to determine who will "most likely be staying on [your] site," and create an extra step for everyone who wants to leave. You're trying to interrupt and override the user's expectations of how his browser will behave.
If you really want to do this, have event listeners for all unload events that aren't triggered by the back button: every link on your page, closing the window, etc. It won't be easy, and you won't be able to catch all events. But you're going to be pissing people off unless you have a good reason for doing this, so if it's really important then put the extra effort in.
tl;dr: Add event listeners to everything that isn't the back button and bring up the dialog in the callback function. It will piss people off, though.
I have a classifieds website, where anyone (no need for login currently) can post a classified. It is PHP based.
The procedure for posting is currently like this:
click on "New Classified" --->
fill in a form of all information and hit "View classified before publishing it" --->
the form submits to a "verify classifieds" page, where users verify their inputs --->
If everything is okay in the "verify" page, then the user hits OK and the classified is published.
The above procedure isn't exactly optimized. The first page (new_classified) where the form is, is pretty good, but the second page (verify) uses x number of hidden inputs in another form, used to contain the previous pages form inputs.
Now you know how it works on my site.
The issue today is that alot of companies want to publish their classifieds, and alot of classifieds at the same time. This means they have to fill out the form again and again currently.
I am thinking about creating a login, for companies only, so that their information is automatically inputted into the form, so all they would have to do is fill out the specific classified details like "headline" and "description" etc.
How should I do this in my case? Sessions?
This means I will have to create a new MySql table (I use MySql mainly) and store company-profiles there.
So do you think converting to sessions is alot of work? Worth it? More reliable?
I have never used sessions so I wouldn't know.
As a last note, you should know that I use a picture upload tool on the first page of "new_classified". When a user choses a file to upload, the page is automatically *refreshed*, and then the image is displayed on the same page under section "images uploaded". I hope the session wont interfere with this approach.
Thanks
I think it is worth your while to do logins, and even on a very basic level it will help you to identify who is using your site etc.
This is probably a big debate around developers, what is the best way to do a good login system, whether it's basic or not doesn't matter, I think the concepts still stay the same.
In your case I would suggest session cookies along with a login table consisting of user details. This would help you to verify the user on more than one occasion during his/her visit to the site.
A login is checked against a user entry in a table and then a session cookie is created. This session you can choose to never expire also.
You can then on every step check that the user is the user that is supposed to be logged in and get the companies details by checking the username. This would make for a better query in my opinion.
Sessions aren't a lot of work and it's relatively easy to learn.
http://www.php.net/manual/en/book.session.php
http://www.9lessons.info/2010/02/php-login-script-with-encryption.html is a good example of what you can do with this. Have a look around still. There are a bunch of these great tutorials on the web.