Page 1 of 1
Does GetHostByName($REMOTE_ADDR) ever fail to get IP? (nt)
Posted: Wed Aug 24, 2005 1:13 am
by ezenu
nt
Posted: Wed Aug 24, 2005 1:48 am
by feyd
$REMOTE_ADDR will not exist unless register_globals is on, which they should not be. Use $_SERVER['REMOTE_ADDR'] instead.
Posted: Wed Aug 24, 2005 11:56 am
by ezenu
Well, I've heard a few times how register_globals should be OFF for security reasons.
However my webhost has it set to ON & I don't think I can change that.
But, will the command ever fail to get their IP? Maybe if they're behind a firewall or proxy?
Posted: Wed Aug 24, 2005 1:27 pm
by Roja
ezenu wrote:Well, I've heard a few times how register_globals should be OFF for security reasons.
However my webhost has it set to ON & I don't think I can change that.
It should be off, and you can in fact turn it off, even in your script.
ezenu wrote:But, will the command ever fail to get their IP? Maybe if they're behind a firewall or proxy?
Yes. Firewalls, proxies, AOL, some Earthlink, national proxies, bounced browsing.. The list goes on.
You don't want to get an IP from a user. Read my sig.
Posted: Wed Aug 24, 2005 2:25 pm
by ezenu
so, if IP addresses are useless for identifying which user is which, then how would I go about preventing a user from spamming a feedback-type form again and again (therefore filling my email inbox)?
users can disable cookies & sessions don't work
Posted: Wed Aug 24, 2005 2:34 pm
by Sander
You can prevent it by making the users login. Once they're logged in, you can easily identify them by their unique ID in the database.
Posted: Wed Aug 24, 2005 3:02 pm
by ezenu
ugg, yeah I can see how that would definitely be a sure-fire way to prevent spamming.
however I don't want users to have to go through all that to register an account (especially since there isn't much of a reason for them to do it). Plus, I always find it annoying when I have to register for stuff all the time
Posted: Wed Aug 24, 2005 3:08 pm
by Sander
Heh, yeah. Still, it's the most secure way to do this. You can't rely on the IP or on cookies. What I would do is to both store the IP and put a cookie on the user's computer.
If some stupid spammer does not knows about cookies, he can't do anything. If some stupid spammer doesn't knows about tracking IP's, he again can't do anything.
Posted: Wed Aug 24, 2005 3:15 pm
by Roja
ezenu wrote:so, if IP addresses are useless for identifying which user is which, then how would I go about preventing a user from spamming a feedback-type form again and again (therefore filling my email inbox)?
users can disable cookies & sessions don't work
Lets restate the problem a different way:
You want SOME users (legitimate users) to use a service, but don't want some OTHER users (spammers) to abuse it.
So, you want to make things difficult for the spammer, but easy for the legitimate user. That means you want to increase the "cost" or difficulty of multiple submissions - since a regular user isn't likely to use the feedback form repeatedly.
To do that, you can tackle either side of the equation - remove the value to the spammer, or make it harder for him.
You aren't very specific about what you are doing. If its truly a "feedback" form, then the public doesn't need to see it. If the public doesn't need to see it, there is no value to a spammer - except getting an email to you. Considering that spammers get emails by the millions, a form isn't worth their trouble for *one* email, unless they can automate it.
So, please, give a little more detail so we can answer with more detail.
However, your comment ignores the facts: Users can disable cookies, sessions can be restarted, AND IP's have no relation to users. All of which make automated attempts to validate a user impossible.
Thats why we have CAPTCHA's (bad, medium-difficulty-to-defeat, horrible usability), moderation systems (depends on the application), and user validation (signup, validate email, etc)..
To give you advice on how to solve your problem, you'll have to be more specific about what the form is, and does.
Posted: Wed Aug 24, 2005 3:17 pm
by Roja
Sander wrote:
If some stupid spammer does not knows about cookies, he can't do anything. If some stupid spammer doesn't knows about tracking IP's, he again can't do anything.
Automated systems don't accept cookies, or if they do, they delete them before the next site access.
IP's are useless too - spammers (and their automated systems) use proxies, dialup aggregators, botnets, and various other groupings of machines to spread their attack out.
Once again, you want to focus on the BEHAVIOR, not the technology.
Posted: Wed Aug 24, 2005 3:29 pm
by Sander
I know, but some 10 year old kid who doesn't know anything about the internet can also spam. If he sees a feedback form and tries to send a few messages with it, he hasn't got a clue about how the site knows that he already sent a message once. He just gives up and leaves the site.
If you can't stop all the spam, you can at least try to stop at least as much as possible of it. Of course, it would be better to somehow prevent everyone from spamming, but if you see no way to do this, this would probably the only thing you can do.
That's how I look at it anyway. Just know that I realize that this isn't the best way to do this

Posted: Wed Aug 24, 2005 4:13 pm
by ezenu
well, the system is a feedback-style form where I ask for name, email, phone, and a few other things then sends a email to my account. The data is also put into a mySQL table which will later be exported to excel.
I wasn't worried about spammers as in high tech companies trying to sell <span style='color:red;text-decoration:blink' title='Alert a moderator!'>grilled spam</span> or something

, but rather people just clicking the Submit button multiple times accidently or purposefully (messing up my data).
Anyways, the system I have now should work fine using IP tracking. It should work well enough since the 'Resubmit time' (min amount of time before someone at an IP can post again) is so short (will be from 15 sec to 5 min approx), that it shouldn't matter.
Posted: Wed Aug 24, 2005 4:14 pm
by Roja
Sander wrote:
If you can't stop all the spam, you can at least try to stop at least as much as possible of it. Of course, it would be better to somehow prevent everyone from spamming, but if you see no way to do this, this would probably the only thing you can do.
On the contrary - I never said it was impossible to stop all spamming. It may be extremely difficult, or require making things incredibly difficult for legitimate users, admins, and take tons of code...
But I definitely didn't say there was no way to do it.

Posted: Wed Aug 24, 2005 4:18 pm
by Roja
ezenu wrote:well, the system is a feedback-style form where I ask for name, email, phone, and a few other things then sends a email to my account. The data is also put into a mySQL table which will later be exported to excel.
I wasn't worried about spammers as in high tech companies trying to sell <span style='color:red;text-decoration:blink' title='Alert a moderator!'>grilled spam</span> or something

, but rather people just clicking the Submit button multiple times accidently or purposefully (messing up my data).
Anyways, the system I have now should work fine using IP tracking. It should work well enough since the 'Resubmit time' (min amount of time before someone at an IP can post again) is so short (will be from 15 sec to 5 min approx), that it shouldn't matter.
Aha. See, now the problem is much simpler!
What you need is called Post-Redirect-Get. Its a common problem in web applications, and here's a big fancy, complicated writeup:
http://www.theserverside.com/patterns/t ... d_id=20936
Simpler solutions:
- Make the insert be conditional.. check the database for an entry like it, and if so, don't insert another.
- Hidden form fields.. Put a number in the form, and into the database. Once that number is posted from the form, remove it from the database. If the number is posted again, and its not in the database, don't add it, give an error ("Slow down!")
- Use javascript to convert the submit button on click to a "Please wait" button that is disabled
There are dozens of solutions - none of which require anything to do with IP addresses, all of which will be more effective.
