Restricting an ip adress to not vote twice

[razorsese]

I have a page whit an article vote button and some comments each whit they're vote button

How i can create a database to restrict an ip adress to vote twice on article and to vote twice on all comments?

 

[floridaflatlander]

How anal are you about the voting, if you want to make sure someone only votes once then you may need to register members but even this has flaws. As far as ip address some people's change often, my ip address(I have comcast) only changes very yr or so. You could also use cookies, it would be easier and if someone wanted to vote twice they'd have to delete their cookies and vote again.

[TimeBomb]

The user's IP - the one viewing your site - can be gotten via $_SERVER['REMOTE_ADDR'].

Store it in the database, and then compare the current IP to the database table that stores the IPs. If a match is found, they've already voted on that IP.

[razorsese]

Well I drop the idea whit ip adress and switching to the user idea;

I'm gonna try whit cookies but I was wondering if I could use a database to limit user vote

For example let's say page 1 has 

: 1 main vote for article

:45 comments to vote

So every time user vote for one comment the column from database decrease by 1 and when it hit 0 it will not allow anymore vote

just for double security

But I think it might be a bad idea in practice

[TimeBomb]

Well I drop the idea whit ip adress and switching to the user idea;

I'm gonna try whit cookies but I was wondering if I could use a database to limit user vote

For example let's say page 1 has 

: 1 main vote for article

:45 comments to vote

So every time user vote for one comment the column from database decrease by 1 and when it hit 0 it will not allow anymore vote

just for double security

But I think it might be a bad idea in practice

 

If you want it to have per-user security instead of per-ip address, I don't see this as that bad of an idea.

When they vote, add a cookie.

If they come in and try to vote, check the cookie.

If the cookie isn't there, check the database.

If they are NOT allowed to vote, put the cookie back in there.

If they are allowed to vote, have them vote and then put the cookie back in there.

 

When the cookie is in place, you won't need to check the database. But you obviously still want to check the database if the cookie isn't there, or else this system can be easily abused.

[floridaflatlander]

How anal are you about the voting ?

 

If not very, use cookies/sessions and set them to expire in the distant future.

Why would someone try to skew your voting? How many times would they do it?

Most people would give it a one time try and if it didn't count again forget about it. They wouldn't go through the trouble of deleting cookies to vote again.

Cookies would be alot  easier and I'd use that unless it is for an important pole or info.

As a note and for comparison I pretty sure my coppermine photo album uses cookies.

 

[TimeBomb]

Most people would give it a one time try and if it didn't count again forget about it. They wouldn't go through the trouble of deleting cookies to vote again.

I will very much so agree with you. Especially with the word "most".

 

Don't wait until something bad happens before you patch in a fix. Just take the extra two minutes, and secure the application now.

There are always people that will try to abuse your application. A lot of the time, abuse and exploiting can be avoided by properly securing your application, including all data that the user may have access to.

[scootstah]

Don't wait until something bad happens before you patch in a fix. Just take the extra two minutes, and secure the application now.

 

The problem is that this sort of thing can't be fully prevented without penalizing innocent users. Making decisions based on a users IP is always not a very good solution, since there is no guarantee that a users IP is unique to that user, or that it will stay the same. Some user's IP changes frequently, other user's share the same IP (like people in a college or in office buildings).

 

So if you simply store the user's IP and not let anyone else with that IP vote again, you're potentially disallowing anyone on the same network from voting.

[TimeBomb]

Don't wait until something bad happens before you patch in a fix. Just take the extra two minutes, and secure the application now.

 

The problem is that this sort of thing can't be fully prevented without penalizing innocent users. Making decisions based on a users IP is always not a very good solution, since there is no guarantee that a users IP is unique to that user, or that it will stay the same. Some user's IP changes frequently, other user's share the same IP (like people in a college or in office buildings).

 

So if you simply store the user's IP and not let anyone else with that IP vote again, you're potentially disallowing anyone on the same network from voting.

Yes, I will agree with you. But, storing data only through cookies is quite situational. Sometimes cookies just aren't secure enough. But restricting purely based on IP is sloppy and overly restrictive.

I haven't looked a lot into the ability to save PHP sessions to a file/database, but perhaps that may work best in this scenario.

A cookie isn't secure because it is data stored on the client's browser. A PHP session is a server-sided per-user key/value storage, though.

 

Normally, they can't be trusted over a prolonged period because they don't last all that long - just long enough for the current session. But, PHP's session_set_save_handler may be able to remedy this, allowing the backend to store sessions upon deletion, instead of just permanently deleting them.

 

But, as I said before, I am not all that experienced with the practice of saving/storing sessions, although it seems possible without too much hassle.

So, if anyone has a better grasp of saving sessions, please don't hesitate to comment.

[scootstah]

Don't wait until something bad happens before you patch in a fix. Just take the extra two minutes, and secure the application now.

 

The problem is that this sort of thing can't be fully prevented without penalizing innocent users. Making decisions based on a users IP is always not a very good solution, since there is no guarantee that a users IP is unique to that user, or that it will stay the same. Some user's IP changes frequently, other user's share the same IP (like people in a college or in office buildings).

 

So if you simply store the user's IP and not let anyone else with that IP vote again, you're potentially disallowing anyone on the same network from voting.

Yes, I will agree with you. But, storing data only through cookies is quite situational. Sometimes cookies just aren't secure enough. But restricting purely based on IP is sloppy and overly restrictive.

I haven't looked a lot into the ability to save PHP sessions to a file/database, but perhaps that may work best in this scenario.

A cookie isn't secure because it is data stored on the client's browser. A PHP session is a server-sided per-user key/value storage, though.

 

Normally, they can't be trusted over a prolonged period because they don't last all that long - just long enough for the current session. But, PHP's session_set_save_handler may be able to remedy this, allowing the backend to store sessions upon deletion, instead of just permanently deleting them.

 

But, as I said before, I am not all that experienced with the practice of saving/storing sessions, although it seems possible without too much hassle.

So, if anyone has a better grasp of saving sessions, please don't hesitate to comment.

 

Sessions use cookies, so if you think cookies are not enough then neither are sessions.

[TimeBomb]

Don't wait until something bad happens before you patch in a fix. Just take the extra two minutes, and secure the application now.

 

The problem is that this sort of thing can't be fully prevented without penalizing innocent users. Making decisions based on a users IP is always not a very good solution, since there is no guarantee that a users IP is unique to that user, or that it will stay the same. Some user's IP changes frequently, other user's share the same IP (like people in a college or in office buildings).

 

So if you simply store the user's IP and not let anyone else with that IP vote again, you're potentially disallowing anyone on the same network from voting.

Yes, I will agree with you. But, storing data only through cookies is quite situational. Sometimes cookies just aren't secure enough. But restricting purely based on IP is sloppy and overly restrictive.

I haven't looked a lot into the ability to save PHP sessions to a file/database, but perhaps that may work best in this scenario.

A cookie isn't secure because it is data stored on the client's browser. A PHP session is a server-sided per-user key/value storage, though.

 

Normally, they can't be trusted over a prolonged period because they don't last all that long - just long enough for the current session. But, PHP's session_set_save_handler may be able to remedy this, allowing the backend to store sessions upon deletion, instead of just permanently deleting them.

 

But, as I said before, I am not all that experienced with the practice of saving/storing sessions, although it seems possible without too much hassle.

So, if anyone has a better grasp of saving sessions, please don't hesitate to comment.

 

Sessions use cookies, so if you think cookies are not enough then neither are sessions.

PHP sessions do not 'use' cookies. While cookies are stored on the user's browser, PHP sessions are stored on the actual web server, and are thus much more difficult to be modified by the user. Security can be put in place to protect sessions, but that is a different subject. While they both provide similar functionality, PHP sessions and cookies are quite different.

 

The main difference between cookies and sessions is that cookies are stored in the user's browser, and sessions are not. This difference determines what each is best used for.

 

A cookie can keep information in the user's browser until deleted. If a person has a login and password, this can be set as a cookie in their browser so they do not have to re-login to your website every time they visit. You can store almost anything in a browser cookie. The trouble is that a user can block cookies or delete them at any time. If, for example, your website's shopping cart utilized cookies, and a person had their browser set to block them, then they could not shop at your website.

 

Sessions are not reliant on the user allowing a cookie. They work instead like a token allowing access and passing information while the user has their browser open. The problem with sessions is that when you close your browser you also lose the session. So, if you had a site requiring a login, this couldn't be saved as a session like it could as a cookie, and the user would be forced to re-login every time they visit.

 

You can of course get the best of both worlds! Once you know what each does, you can use a combination of cookies and sessions to make your site work exactly the way you want it to.

[scootstah]

The PHP session is stored as a cookie. If you delete the cookie, you destroy the session.

[TimeBomb]

The PHP session is stored as a cookie. If you delete the cookie, you destroy the session.

The session id is, by default, stored in a cookie. Not the data.

 

With a cookie, the time remaining is stored on the user's browser. The user can modify the time remaining to, ex., 0 seconds left.

With a session, the time remaining is stored on the web server. The time can not be modified by the user, and thus is more secure.

 

You can actually disable the use of cookies and enable the use of a GET parameter to handle session IDs. This would solve the reliance on cookies as well as many of these issues.

See http://ie.php.net/manual/en/session.configuration.php#ini.session.use-cookies and http://ie.php.net/manual/en/session.configuration.php#ini.session.use-trans-sid

Obviously, because sharing a URL is a lot easier than manually inserting/modifying a cookie, this is a bit less secure than using the default cookies storage method.

 

There are other alternatives as well, but for the average application and the average programmer, as scootstah said, your best bet is simply using a cookie.

[razorsese]

I was wondering if i can create tables for every article my website have to store the user allowed comments to vote;

Is there any limit for how many table a database can have?!

And this is a viable solution?!

[scootstah]

The PHP session is stored as a cookie. If you delete the cookie, you destroy the session.

The session id is, by default, stored in a cookie. Not the data.

 

With a cookie, the time remaining is stored on the user's browser. The user can modify the time remaining to, ex., 0 seconds left.

With a session, the time remaining is stored on the web server. The time can not be modified by the user, and thus is more secure.

 

Once again if you delete the session cookie the session will be destroyed and all data in the session will become unset. Therefore if you set a session flag like $_SESSION['already_voted'] = true; and then you delete the session cookie, this data is unset and the session array will be empty.

[floridaflatlander]

I was wondering if i can create tables for every article my website have to store the user allowed comments to vote;

Is there any limit for how many table a database can have?!

And this is a viable solution?!

 

You can figuratively create as many tables as you want per db.

 

If I had to guess right of the top of my head you could probably put all the votes for all the articles in one table. To create a table for each article would be a pain.

 

If the votes are important make user join your site before they can vote and you can then make sure(more or less) that there is only only vote per person.

 

What I like about cookies and/or sessions is that it would be easier and almost as accurate.  Average Joe's like me would have to go into the Firefox menu or IE's menu and delete their cookies to vote twice. I'm sure there are smarty pants out there somewhere that could make an automated system to delete their cookies and vote again but why would they do that for your site?

[TimeBomb]

The PHP session is stored as a cookie. If you delete the cookie, you destroy the session.

The session id is, by default, stored in a cookie. Not the data.

 

With a cookie, the time remaining is stored on the user's browser. The user can modify the time remaining to, ex., 0 seconds left.

With a session, the time remaining is stored on the web server. The time can not be modified by the user, and thus is more secure.

 

Once again if you delete the session cookie the session will be destroyed and all data in the session will become unset. Therefore if you set a session flag like $_SESSION['already_voted'] = true; and then you delete the session cookie, this data is unset and the session array will be empty.

 

You cut out the part of my post that breaks this logic.

You can actually disable the use of cookies and enable the use of a GET parameter to handle session IDs. This would solve the reliance on cookies as well as many of these issues.

See http://ie.php.net/manual/en/session.configuration.php#ini.session.use-cookies and http://ie.php.net/manual/en/session.configuration.php#ini.session.use-trans-sid

 

And in terms of database tables - as floridaflatlander said, you can have as many as you want, but it's bad database design to have more tables than you need. If you want to only allow registered users to vote, then there are multiple valid ways you could go about designing a database to support this.

[scootstah]

The PHP session is stored as a cookie. If you delete the cookie, you destroy the session.

The session id is, by default, stored in a cookie. Not the data.

 

With a cookie, the time remaining is stored on the user's browser. The user can modify the time remaining to, ex., 0 seconds left.

With a session, the time remaining is stored on the web server. The time can not be modified by the user, and thus is more secure.

 

Once again if you delete the session cookie the session will be destroyed and all data in the session will become unset. Therefore if you set a session flag like $_SESSION['already_voted'] = true; and then you delete the session cookie, this data is unset and the session array will be empty.

 

You cut out the part of my post that breaks this logic.

You can actually disable the use of cookies and enable the use of a GET parameter to handle session IDs. This would solve the reliance on cookies as well as many of these issues.

See http://ie.php.net/manual/en/session.configuration.php#ini.session.use-cookies and http://ie.php.net/manual/en/session.configuration.php#ini.session.use-trans-sid

 

Because that's a bad idea that can lead to session hijacking, so it's not a valid alternative.

 

The only way to semi-reliably do what the OP wants is to have user accounts. You could use logic to make it so user's could only vote once, which means you would need multiple accounts to vote multiple times. Still possible, but more work.

 

Other than that, it cannot be done reliably without punishing innocent users. You either block too many users, or don't block enough users.

[TimeBomb]

The PHP session is stored as a cookie. If you delete the cookie, you destroy the session.

The session id is, by default, stored in a cookie. Not the data.

 

With a cookie, the time remaining is stored on the user's browser. The user can modify the time remaining to, ex., 0 seconds left.

With a session, the time remaining is stored on the web server. The time can not be modified by the user, and thus is more secure.

 

Once again if you delete the session cookie the session will be destroyed and all data in the session will become unset. Therefore if you set a session flag like $_SESSION['already_voted'] = true; and then you delete the session cookie, this data is unset and the session array will be empty.

 

You cut out the part of my post that breaks this logic.

You can actually disable the use of cookies and enable the use of a GET parameter to handle session IDs. This would solve the reliance on cookies as well as many of these issues.

See http://ie.php.net/manual/en/session.configuration.php#ini.session.use-cookies and http://ie.php.net/manual/en/session.configuration.php#ini.session.use-trans-sid

Because that's a bad idea that can lead to session hijacking, so it's not a valid alternative.

I disagree. Session hijacking can be prevented more times than not via proactively securing your application. Sessions can still be hijacked if you are using cookies only (which is default); the main difference being it takes a little bit longer to mess with a cookie than it does a URL, and thus it will be easier for a 'novice', if you will, to 'hijack' a session if it is a URL parameter versus a cookie.

 

I will agree that the simplest way to handle this issue is either requiring a user to be logged in, or through cookies.

[scootstah]

I disagree. Session hijacking can be prevented more times than not via proactively securing your application.

 

Indeed, and making PHP accept session ID's from only cookies is one of them.

 

Sessions can still be hijacked if you are using cookies only (which is default); the main difference being it takes a little bit longer to mess with a cookie than it does a URL, and thus it will be easier for a 'novice', if you will, to 'hijack' a session if it is a URL parameter versus a cookie.

 

Sure, but the circumstances are different. Allowing session ID's in the URL can be manipulated in a number of ways. For example if the site doesn't use SSL then every out-going link will potentially contain the session ID which can be found in the receiving sites HTTP referrer.

 

It is much more difficult for a third party to read a user's cookie from another website, modern browsers prevent that. You'd need to explicitly send the cookie data from the original site to a third party site - like through an XSS attack, which is a lot easier to manage.

 

Passing session ID's through the URL creates more problems than it solves. In fact, it doesn't even solve this problem - the client can still reset the session data.

[TimeBomb]

I disagree. Session hijacking can be prevented more times than not via proactively securing your application.

 

Indeed, and making PHP accept session ID's from only cookies is one of them.

 

Sessions can still be hijacked if you are using cookies only (which is default); the main difference being it takes a little bit longer to mess with a cookie than it does a URL, and thus it will be easier for a 'novice', if you will, to 'hijack' a session if it is a URL parameter versus a cookie.

 

Sure, but the circumstances are different. Allowing session ID's in the URL can be manipulated in a number of ways. For example if the site doesn't use SSL then every out-going link will potentially contain the session ID which can be found in the receiving sites HTTP referrer.

 

It is much more difficult for a third party to read a user's cookie from another website, modern browsers prevent that. You'd need to explicitly send the cookie data from the original site to a third party site - like through an XSS attack, which is a lot easier to manage.

 

Passing session ID's through the URL creates more problems than it solves. In fact, it doesn't even solve this problem - the client can still reset the session data.

Very well. Tinkering with sessions to the point where my initial suggestion is valid is far too much of  a hassle than it is worth. I'll rest my case.

 

I'll once again recommend either using cookies, or, if it is that important that the same person doesn't vote more than desired, requiring them to be a registered user (albeit than you have to worry about duplicate accounts being created to vote more than once per person, but that should be more easily manageable).