Hi,

I'm not sure if anyone already does this, but would it be possible to ban submissions by referring IP address? (Eliot I've seen the thread for banning by domain name, but I think this is slightly different?)

Someone appears to have duplicated my submission form including the URL of the add.cgi script and is using it to submit hundreds of adult sites, or at least their members are. (I've used the contact details from the RIPE database for their IP range, but haven't had any response from them so I'd like to ban them.)

Could add.cgi check the referring IP address and forward to an error page, despite the fact that the script call is being made to a URL within my domain?

All the best
Shaun

Don't you have $LINKS{db_referer} defined in the Links.pm module? That works for me...in addition to using the following modifications:

1) Login required to add, modify, etc.
2) Confirmation screen
3) Double check submissions before they are entered (prevents reloading the page and added duplicated submissions)

etc....

Regards,

Eliot Lee
http://anthrotech.com/

Hi Eliot,

Yes, I have referrer's set as follows:

$LINKS{db_referers} = ['www.qango.com','qango.com']

I don't have a login screen, and my suggestion form is a single page with no confirmation. I'm not entirely sure how the 'spam' is getting through as I assumed the db_ref.. took care of 'off-site' submission attempts and blocked them.

Could it be that db_referers isn't working?

Thanks
Shaun

Don't suppose they're German sites? I've been getting a ton of them, with some days having more than 100 such submissions, but they're easy to mass delete from the Validate table through the SQL Monitor, since they typically all have the same email address or URL. Still, quite annoying. What's the motivation for endlessly submitting such garbage when it clearly won't be accepted? Hoping something will slip through the cracks?

I suspect (although I have no way of knowing with any certainty) that lists are going around with Links sites' addresses for mass-submission purposes. I hope I'm wrong...

Dan

Hello, Dan.

There is a long thread in the Links 2.0 Discussion Forum called German Spammers.

Regards,

Eliot Lee
http://anthrotech.com/

Thanks, I haven't browsed that forum in quite some time. I'll have to take a look at it.

Dan

Sheesh, "long" is right! I'm curious about one of the things you (Eliot) said in one of the threads:

Are the majority of people requiring user accounts in order to submit sites? That seems like a major deterrance for legitimate submissions, considering a link submission is a one time process for the vast majority of pople. Heck, most of my users don't even want to bother with forum registration if they visit regularly...

One thing I don't understand about the German spam problem is that I get them despite having $LINKS{db_referers} set to my domains. Either it doesn't work correctly, or they are auto-submitting from on-site somehow. Thoughts?

Dan

I am...and with a portal type site where members can do a bunch of things, it is nice have a centralized login process (one login per user to access all interactive options)...also in terms of quality control/assurance, logins are very useful to ensure that records are edited by appropriate users.

Actually, there is another thread in the Links 2.0 Customization Forum that discusses auto-submission...You can write a LWP script that can auto-submit and by-pass the db_referer....

That is why adding something like random codes before submitting or having all users manually login is much better...

I've used logins both in Links 2.0 and LINKS SQL and I've never been spammed (*knock on wood*).

Regards,

Eliot Lee
http://anthrotech.com/

Dan, qango, or any other loyal v.1.X users out there,

Here is what I've done to add a simple Check IP Address code hack (of course, this is not foul-proof due to dynamic IP addresses of dial-up connections, but may help)...

1) Add the following table in your LINKS SQL database:



(of course, the latter two columns/fields are optional)

Name the table something like Ban_IP.

2) Add the "bad" IP Addresses into the IPAddress field via MySQLMan or if you want you can add links in the sub html_navigation routine in the Admin_HTML.pm file...using the new table name in the query string for adding, editing, deleting.

3) Add the following codes in the sub main section of your add.cgi script:



Yes, this could be used for domains as well...

This is a lot faster than looping through an array of IP values...like creating an array in the Links.pm and checking for IP addresses. In addition, you can make notations about why the IP address is banned in the Ban_IP table by adding an additional field/column.

BTW: I am using the above codes in my Create Account script in my member's site...and they work...I've also cleaned out customized codes to work with the out-of-box version of Links SQL v.1.13.

Regards,

Eliot Lee
http://anthrotech.com/

Eliot,

Thanks for the code - I think it's just what I was looking for

All the best
Shaun

Eliot,

Just wanted to say 'thanks' for the code above

I installed it last night and after a few tweaks (a 'my' missing on $BANIPDB = new Links::DBSQ.... and removing print $in->header();) it works perfectly.

I'm curious as to how it could be adjusted to use domain names, i.e.; checking the first part of a domain against the referring domain? Maybe a separate table for domains and a double-check against both the IP Addr. and domain name?

All the best
Shaun

Sorry, qango.

I fixed the above codes (with the exception of header call, since in my codes, it seemed to work with it.)

About domains...what you could do is use Socket.pm to check the domain address...I posted codes for checking domains (like for email addresses) in this forum before.

You don't really have to add another table...just add another column called Domain and allow NULL values for both the IP Address and Domain. In order to maintain integrity, you should add a primary key (ID column).

Regards,

Eliot Lee
http://anthrotech.com/