BuddyPress.org

@David that’s what wp-hashcash does. it adds a hidden form field whose value is set only via JavaScript when the page loads in the browser. if the browser is a bot, the value of the field will not be set because bots usually do not have JavaScript capabilities. It isn’t the field itself that makes the difference, it’s what it contains that enables you to tell a human from a bot.

I have adjusted the wp-hashcash plugin to work with buddypress signup. Here is what I did: I got the wp-hashcash plugin and I added the following code to the file:

global $bp;

// get our options
$options = wphc_option();
$spam = false;
//if( !strpos( $_SERVER[ ‘PHP_SELF’ ], ‘wp-signup.php’ ) )
//return $result;

// Check the wphc values against the last five keys
$spam = !in_array($_POST[“wphc_value”], $options[‘key’]);

if($spam){
$options[‘signups-spam’] = ((int) $options[‘signups-spam’]) + 1;
wphc_option($options);
$bp->signup->errors[‘spam’] = __(‘You did not pass a spam check. Please enable JavaScript in your browser.’);
} else {
$options[‘signups-ham’] = ((int) $options[‘signups-ham’]) + 1;
wphc_option($options);
}

}
add_action( ‘bp_signup_validate’, ‘wphc_check_signup_for_bp’);

function wphc_error_hook_register_page(){

do_action(‘bp_spam_errors’);

}
add_action(‘bp_before_register_page’, ‘wphc_error_hook_register_page’);

Then, under the line (line number about 507)

I put this line:

Then I activate the plugin. It should keep spam bots from being able to create accounts, but humans spammers can still do it. Anyway, if you can’t get it to work, let me know via PM and I will try to send you the file.

Later

I am having major problems with spam as well. Ironically it started as soon as I put my link in the showcase thread on this forum. I think the spam bots are looking there for easy targets as well.

Why do people make spambots that don’t even advertise stuff and just waste everyone’s time filling sites with meaningless crap. Is it like they are trying to sabotage Buddypress?

How does one submit domains and sites and IP addresses to spam traps.

http://www.bp-tricks.com/tips_and_tricks/stopping-the-sploggers/

i guess this is one of the best trick against spam blogs and “wild” registrations.

Step 1 and 2 are a bit obvious, but 3 and 4 are really efficient.

Keep in mind that on a wpmu site each blog created by a member has his first post and comment appearing on the default template – the good ol’ kakumei… on which is also written “powered by…” ( Step 2 is only for main blog i think) Spam bots eat this with delectation i suppose.

Spam programs are written to bypass signup. Well. I presume other narrow words like join, fall in, get together are also activ in such programms. But what do these programms if you choose “groink” or “methabolic” ? So follow the explanation and choose a really original word for your signup redirection. This works well for the moment. And don’t forget to put the functions.php file the in mu-plugins folder (to be theme independant).

To use in addition with some other solutions (wp-ban, invisible defender, …) of course.

i just installed this system, and yes it send the validation email, so the users may be compromised in error…

on my side i added a TOS plugin *(my own), so people have to check it and the input name have a name the bots are not recognising so they do not check it before registration…

@Harry

Yes, my Privacy Component works just as I described. It is an advanced beta available for testing. See this thread for more details: https://buddypress.org/forums/topic/buddypress-privacy-component-an-update/page/3#post-30574

@David

I wouldn’t give users the option to set it to friends only. Or at least… I would like the site admin to have the ability to disable that option.

In my Privacy Component, the site admin can choose to disable this feature.

But, to get back on topic, I agree that the best solution is the one that requires the brunt of the filtering to be accomplished through invisible, behind-the-scenes techniques. Requiring users to prove that they are members and not bots should not be the first line of defense. I think it is okay, even necessary for registration purposes. But that is a one time occurrence. After that, the system should do more of the policing.

Concerning your second link above, perhaps we could create a new CAPTCHA that could harness the collective intelligence of site members to solve the Unified Field theory.

Word. Patch it!

I’ve been having sign up spams (arguably a different issue) on my BP install, and just shut all signups down until I could figure out what to do about it.

Scouring the WordPress MU forums has made me realize three things:

1. Spamming is a huge problem for WordPress MU users

2. I’m betting that BuddyPress will/might have even larger problems due to the very nature of the beast (it’s all about users, right? Which is where the bots/spammers gravitate)

3. There are no sure-fire methods for preventing spammers

…well, there’s a fourth, too…

4. Many of the old hats on the WordPress MU forums are getting tired of explaining how to defend against so-called “splog” signup bots and spammers.

Just some observations, as BP just received its first official spammer. (Yes, I got the email too, and saw the small twitter firestorm this morning over it.)

I posted this elsewhere but it now belongs as part of this discussion: When using Buddypress, should /wp-signup.php result in an blank page or the registration form (or redirect to /register)? If the issue described here exists, how do you get the proper default buddypress behavior?

see: http://ttacconnect.org/wp-signup.php

I could delete /wp-signup to remove the errors but I’d like to understand how bp and wpmu is designed to work (are there any consequences for deleting wp-signup.php?).

I know BuddyPress is using /register.php and not /wp-signup.php. But when /wp-signup.php is hit (typically by spam bots) a PHP Warning is generated. No white space outside of php closing tags in header.php. I’m not too concerned about that as I figure if it’s working as it should (no registration form), then the php warning will take care of itself (and not be generated). So what needs to change to get /wp-signup.php to result in a blank page?

PHP Warning: Cannot modify header information – headers already sent by (output started at xxxx/bp-sn-parent/header.php:3) in xxxx/wp-includes/pluggable.php on line 865

See no Warning and no Registration Form (blank page). Is this the proper default buddypress/wpmu behavior?

http://nourishnetwork.com/wp-signup.php

Here /wp-signup.php was deleted and results in a page not found:

http://memomu.com/wp-signup.php

wpmu 2.8.6 with active plugins on main bp site:

bp 1.1.3, bp-groupblog, auto group join, Group Forum Subscripton, bad behavior

@michael -> de nada

Attempt will continue a few days after you did changes. The time spam robots refresh their attack strategy, heu, their cache…

I couldn’t say to you “be patient”, i know you are, but…wait a little ? This is not Nescafé, but computing…

Same problem,started about a few days ago. Bots are signing up a few times a day, firstnamelastname19xx.

Interesting is that I notice in my stats some ip found my site by searching for “proudly powered by WordPress MU and BuddyPress”.That could be a reason that this particular bot is finding and attacking bussypress installs.

If this bot is getting past Captcha, I would recommend applying a reverse Captcha technique. Just do a bit of Googling on this, it uses a hidden field as a honey pot which bots will fill in, but normal users will not. When filled in you can redirect them to a page of your choosing.

Please report your findings and how you deal with this as it would be very helpful.

Data on who viewed a given user’s profile is not stored in the database. To accomplish this task, you would have to write your own plugin and add at least one new table to the DB.

However, depending on how the plugin was coded, on even a moderately active site, this/these new table(s) could grow to a very large size. For instance, if a given site was not set up to disallow viewing of users’ profiles unless the viewer was logged in, all sorts of useless visitor hits would be encountered–unknown actual people viewing a profile, search engine bots visiting a profile for purposes of indexing, etcetera.

Of course, the solution would be to code the plugin to ignore those type of hits and only log actual logged in member views. But then the number of true views would be greatly undercounted.

i don’t know if robots go directly into db, or use the wp code…

but one thing you can try is to hack a little the register_new_user function in wp-login.php

to ban some email domains like “XXXX@myspacee.info” witch massevely occurs in the past last weeks….

function begins at line 228 (v. 2.8.4a)

add this on line 233

$email_check = explode(“@”, $user_email);

insert also this at line 248

} elseif($email_check[1] == ‘myspacee.info’) {

$errors->add(‘invalid_email’, __(‘ERROR: The email address isn’t correct.’));

insert the same code and change the mail domain name if you need to ban more domains

In use with invisible-defender, wp-ban and wp-spamfree i think you would be quiet for a moment with unwanted registering of blogs or users.

The tables in the db don’t matter if the plugin that they belong to isn’t running. I guess I’m not understanding what the problem is. The site functions fine but you see errors about 404s and 500s in the log when bots come through looking for things that aren’t there?

If so then you’ll just have to wait until the bots index your current site properly. What’s the big deal? This isn’t a bp issue.

On another topic…is it good to create a ginormous robots.txt file? I’m wondering if that slows down your site at all.

I would place only what you need in your robots.txt file. The link I provide was just to show you that there are many, many bad bots out there. I would not implement the robots.txt file they recommend.

The fact hat yu are getting 500 instead of 404 error codes is a good clue. There must be some specific error showing up in Apache’s error log whenever that is fired. Please create the 500 error again, notice the exact time, and then check the log. What does it say?

Also, sometimes you can get a 500 error if directory or file permissions are not properly set. Where appropriate, they should be 755. Everything in /plugins/ that is BuddyPress specific should be set to 755.

A couple of additional questions while I’m at it:

1. Have you searched the WPMU forums for 500 Internal Server Error thread? I think this may be more related to you WPMu install than BuddyPress?
2. Are you using some special permalink structure? That should not be causing the lack of 404’s but every bit of info helps.
3. Did you carefully follow the readme.txt file that comes with WPMU?
4. Is this a new WPMU 2.7.1 install, or did you upgrade from an older version?

Rich-

Just a couple more thoughts while I think about your situation.

Have you determined the offending party that keeps triggering the redirects? Is it Googlebot-image? Have you disallowed it from searching your site with a robots.txt file?

If so, then it probably is not actually the Googlebot-image spider but a spam spider attempting to masquerade as the Google image bot. A robots.txt file cannot stop a spider from crawling your site. Reputable search engines honor the robots.txt file requests, unscrupulous ones ignore it.

For your information:

http://www.webmasterworld.com/search_engine_spiders/3204487.htm

http://perishablepress.com/press/2009/03/29/4g-ultimate-user-agent-blacklist/

Are you using Firefox? With Firefox and the Web Develoepr Add-on, you can get a lot of information about errors.

301 Redirects:

http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=93633

http://www.seomoz.org/blog/url-rewrites-and-301-redirects-how-does-it-all-work

Using your robots.txt file to block googlebot-image from discovering your image files:

http://www.google.com/support/webmasters/bin/answer.py?answer=35308

Make sure you block only the image directories that you do not want indexed.

Also, if you do not use Google’s Webmaster Tools, you may want to investigate. This service offers many tools, including a list of which files are throwing 404s. http://www.google.com/webmasters/tour/tour1.html

Do you mean while I get this situation worked out? Or do you mean that people are working on this because numerous people have been getting this issue?

I’m not sure that the word numerous applies as I’ve only seen a half dozen or fewer threads with this particular issue. Remember, one person’s 404 is not necessarily the same as the next persons.

This type of issue often comes down to one or more factors: bad install, using too old a version of WPMU or BP, plugin conflict, custom theme issue, apache issue, ISP limitations.

We can try helping you with most of these but do not have any control outside the core of the BuddyPress code. We investigate as best we can with the information provided and if it is caused by BuddyPress, offer a fix in trunk.

I see in another thread that you are on Slicehost. I’m with them as well. Since you have to set up your own slice, there may be an apache issue. So, to better understand you particular issue, please provide some more details:

1. Have you tried deactivating all non-buddypress plugins, wp-super-cache in particular?
2. Have you tried using the default .htaccess file that ships with WPMU?
3. Are there any PHP errors in your log files?
4. what are the other listed errors in your apache log?

So i traced the error to my access log and I found that these errors are being caused by some site requesting a file that no longer exists

While this issue is being worked out, you should either block the offending site(s) from attempting to accessing the non-existent files, or you should do a 301 redirect of the moved files–or at least the moved directories.

Furthermore, you can block the Googlebot-Image bot in your robots.txt file. Although the image bot should not be causing the issue since it is just searching your site gathering information. It is not requesting files, it is discovering them.