hi guys
i have created a html and php based voting page. i want poeple to only vote once can u give me advice either i should use cookies or ip address. and if u get me started as well i will apreciate it thanks :-| :-| :-|
hi guys
i have created a html and php based voting page. i want poeple to only vote once can u give me advice either i should use cookies or ip address. and if u get me started as well i will apreciate it thanks :-| :-| :-|
Short, practical advice for that ties the existing replies together and adds safe options for different needs.
For low‑friction polls (casual, noncritical): use a long‑lived, cryptographically strong token stored in a cookie and record a hash of that token server‑side. That keeps the UI simple and avoids the false negatives that come from shared or dynamic IPs (as hinted). It is not foolproof—users can clear cookies or use multiple browsers—but it is usually fine for opinions or small-site polls (the point and made).
If you want stronger assurance without forcing full accounts: add email confirmation or one‑time vote links, a simple CAPTCHA to stop automated voting, and soft rate limits by IP/window to slow abuse. Store minimal evidence (poll_id, option_id, token_hash, timestamp, truncated IP, user_agent) and use server checks to reject duplicate token_hashes for the same poll.
Example schema and flow (illustrative):
CREATE TABLE votes (
id INT AUTO_INCREMENT PRIMARY KEY,
poll_id INT NOT NULL,
option_id INT NOT NULL,
token_hash CHAR(64),
ip VARCHAR(45),
user_agent VARCHAR(255),
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
); When recording: compute a secure token, set it as an HttpOnly Secure cookie, store a server-side HMAC/sha256 of the token, then reject inserts for the same poll_id + token_hash.
For high‑integrity voting (official or sensitive polls): require authenticated accounts and verified email or external identity (OAuth). and point toward a fuller database model—good for audits—but avoid collecting unnecessary PII (do not store SSNs). If you do retain personal data, encrypt it, log vote actions for auditing, and check applicable privacy laws.
Quick checklist: set Secure+HttpOnly cookie flags, hash tokens server‑side, add CAPTCHA/rate limits, prefer account+verification for strict one‑person enforcement, and keep logs for auditability.
Jump to Post— Comatose 290Using their IP address is generally a bad idea. This stems from the fact that not everyone has a static (permanent) IP address. People who use dial up, for instance, will not always get the same IP (in fact, it's usually different). So, what happens if you get 2, or …
Jump to Post— paradox814 1if you have a members section make sure they are logged in and then store in the database who has already voted
Using their IP address is generally a bad idea. This stems from the fact that not everyone has a static (permanent) IP address. People who use dial up, for instance, will not always get the same IP (in fact, it's usually different). So, what happens if you get 2, or 3 people that use the same ISP. One person votes, and gets offline. Someone else signs on, stumbles across your site, with the same IP as the first person.... they can't vote now.
Cookies are a good idea, but keep in mind that cookies can be erased/refused by the visitor. There is always a way for someone to get around it, so that they can vote more than once if they really want to.
I think that you should use cookies and not be fussed about repeat votes.
If someone wants to keep on revoting again and again then their love for that thing should add weight to their vote. just an opinion.
Yup! me too agree with that (cookie)!
well most of the people nowadays use proxy`s too :p
if you have a members section make sure they are logged in and then store in the database who has already voted
The only viable way to begin this application is with a solid data definition and schema for your Voter's database. You need to provide a User Record with such fields as Name, Address, City, State, Zip, and Telno. You may need to treat all those fields as part of an aggregate key to uniquely identify the user. Or you store Drivers License or SSN but then how will you ensure the data is valid ... you will need access to a State or Federal databse - GOOD LUCK.
Thus if your database and web app are to ever get off the ground they definitely need to be sanctioned or endorsed by political interests. Wouldn't hurt to get to know the local congressman. Key things to consider: always encrypt any sensitive user data, and generate a time sensitive key the user has to enter (for example, like the one used when you purchase tickets on TicketMaster's website ).
Note, this database has to be bullet-proof, and have plenty of statistics. At the end of the day your system will be put on trial by people that lose elections as well as proponents of other solutions. So in the final analysis if the data cannot be defended then your app is not only a liability but possibly a target for "disenfranchised" voter lawsuits. Put it this way, you dont want your app to be considered the next hanging chad.
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.