Add Referrer Banning

What is the point of referrer banning? To stop people from linking your site? I'd think this is only useful for 0.001% of all Drupal sites.

I've asked Robin to implement this because a referrer spammer was spamming drupal.org with porn referrers. This was annoying because it made the "top referrers" page basically useless. I only got rid of the spammer because Kjartan grepped the apache logs for me and told me the IP.

dries, take a look at http://drupal.org/admin/logs/referrers. mine is even worse, nearly 15% of all referrers are pr0n sites. so i do think it is usefull to ban based on referrer, not to prohibits linkers but referrer spammers

I'm still not convinced this feature is needed. I'm tempted to say "won't fix" but I'll let this patch float in the review queue until enough people showed interest in it.

A useful feature for sites plagued by the spammers on the net - another sad example is http://www.xmlrpc.com/stats/referers .

I'd like to see this feature, but I would make a change to the patch.

In statistics.module, + array('data' => t('Ban domain')) isn't exactly clear. We know what it does in the context of this issue, but I can see some of my users thinking that it will do a DNS lookup and ban any users trying to visit from another ISP. If it were my patch, I'd make it 'Ban visitors clicking from this webpage', but that might be wordy for some of you.

As a sufferer of referrer spam (my logs+cache+sessions tables added over 20MB to my database, causing me to go over-quota with my hosting service == cost; as well as the increased traffic making my site go 25% over bandwidth allowance == more cost) would the referrer block generate any output (i.e a 404 message) or would Drupal output a null page (such as cron.php)?

My 'over-bandwidth' problem is not going to be helped if each request gets a 404 message!

I know lighttpd has this feature... maybe you would want to use it instead of apache it seems to have a lot fo features apache is missing plus it uses less load and memory... maybe drupal.org should of swaped to it when it was having load problems... to late to sudgest it now... but if drupal.org ever start getting load problems again it might be the first thing you would want to do.

Patch didn't apply anymore (tried to re-add '?>'). Here's an updated patch. From a quick glance the code looks good, but I didn't test thoroughly.

+1 for the feature, though.

+1

+1

+1 on this feature. but I'd like an option to redirect specific referes to specific path.

Patch Bingo:

Sounds viable and it did have lots of support but since Dries was tempted to change the status to 'won't fix' in July 31, 2005 and nothing more has happened here since September I'll do the same now.

This is to give you a chance to reopen this issue by marking it patch (code needs work) and I'll be happy to reroll the work done to HEAD and adding the specific path functionality requested if you can motivate with enough reason to do so.

Let yourself be heard...

Not sure what happened here. I'm reopening this to see if anyone wants this added to 6.x. I do.

+1

example... http://www.roadcarvin.com - We're getting hammered by referrer spam - it appears to be a botnet. Can't (efficiently) ban by IP because the IP addresses are spread out all over the place. By the time you notice that an IP address is being used and ban it, the botnet is using another batch of machines.

Need a way to ban referrers by regular expression, not just static text...

I also get referrer spam, so +1, bumping.

subscribe!
what about user-agent banning? or redirecting

+1 This is definitely a feature that Drupal sites would benefit from. Although you could potentially handle this at the infrastructure level (webserver), I think it's most likely that a site administrator who is generating the referrer stats in an organization would like to have this functionality right at their fingertips. Banning on regex, or partial names with wildcards would be useful. Keep in mind that the 'referring site' does not actually have any links from their domain to yours. They simply send out a crawling bot that provides falsified 'referrer' headers.

Patch need to be re-rolled.

Not just drupal_is_denied() - access rules is gone too, including the table. #228594: UMN Usability: split access rules into an optional module

Wonderful patch, thanks Robin; i can't wait until it'll fixed :P

Coder only spotted a few minor problems with the patch:

system.install : @@ -568,6 +568,29 @@
Line 4: There should be no trailing spaces
Line 26: There should be no trailing spaces

system.module : @@ -503,22 +503,44 @@
Line 20: There should be no trailing spaces
Line 41: There should be no trailing spaces

Robin, wonderful patch! Definite a life saver especially for users on shared hosting.

This should've made it to D5, lets please get this to D7. Now I can regain some meaningful stats back in my Drupal logs!

Patch no longer applies.

maarten@VRIEZER:/var/www/home/d7$ patch -p0 < referrer_banning\[1\].patch
patching file includes/bootstrap.inc
Hunk #1 succeeded at 915 (offset 8 lines).
Hunk #2 succeeded at 930 (offset 8 lines).
Hunk #3 FAILED at 1054.
1 out of 3 hunks FAILED -- saving rejects to file includes/bootstrap.inc.rej
patching file modules/statistics/statistics.admin.inc
Hunk #2 FAILED at 123.
1 out of 2 hunks FAILED -- saving rejects to file modules/statistics/statistics.admin.inc.rej
patching file modules/system/system.admin.inc
patching file modules/system/system.install
Hunk #2 succeeded at 3071 (offset -1 lines).
patching file modules/system/system.module
Hunk #1 FAILED at 171.
Hunk #4 succeeded at 2062 (offset 6 lines).
1 out of 4 hunks FAILED -- saving rejects to file modules/system/system.module.rej

Is this still as relevant as it was in 2005 o_O? Put status back if you feel this is still needed.