KZeni

Thanks Marco!

In regards to cleaning a database with previously stored passwords, it seems that the wp_signups table can have the meta info cleared for any user that has already been activated (since this info has been copied to the “active” location for user info).

Then there’s just the users that have yet to be activated. These still need the password to remain intact in order for that password to be used for their login, and this is the expected behavior moving forward. These signups can be purged at the administrator/owner’s discretion if they aren’t activated within a certain duration.

This isn’t implemented within the plugin, but I’m just stating possible actions that can be done to the database for others looking for suggestions. *I should state these methods are, as yet, untested so be sure to backup your database before doing anything (which you should be doing anyway).

Yup, I see what you mean. I’m somewhat curious what happens to sites that had this set pre-2.3.12… will the users created before the update be left untouched, or is there some way to go through & clean those up when the update is first ran? A thought.

Thanks for taking care of this Marco!

I too came across this.

Would there be some way to remove the password that’s stored in wp_signups after that user has a user_pass present in wp_users? I’m not sure when would be the best point in the process to check for that, but I don’t see why the password would need to be stored there indefinitely if it’s only needed for part of the registration process. Right?

In leu of a full fix… the addition of a note next to the option on the settings page mentioning this, otherwise unknown, weakening of password security would be nice to see.

Thanks!

Ah, okay. Thanks!

@martin Seems that this is yet unfixed as of version 3.0 (at least the troublesome code mentioned above hasn’t been changed).

I can confirm that @wrk’s fix works when using this plugin on a multi-site install that uses separate domains. I’ve posted it to github in hoping that it might get patched in.

I updated the AddThis plugin to 2.4.3 to see if this issue was resolved, but it was not. I decided to look into this problem.

The cause seemed to be to the “attest” variable that was being added via the check_for_footer() function in includes/addthis_addjs.php. I ended up making the following modification & it fixed the problem…

Line 124 changed from:

$url = add_query_arg( array( 'attest' => 'true') , home_url() );

to

$url = home_url();

Lines 135-138 changed from:

if ( $_GET['attest'] = 'true' )
{
    add_action( 'wp_footer', array($this, 'test_footer' ), 99999 ); // Some obscene priority, make sure we run last
}

to

add_action( 'wp_footer', array($this, 'test_footer' ), 99999 ); // Some obscene priority, make sure we run last

Everything seems to be working now as far as I can tell. I saw that check_for_footer() really isn’t called anytime other than first time visiting the site admin (by way of the update_wpfooter() function) & on the switch_theme action. I added a switch_theme action that echoed some test text in a separate plugin to see if switch_theme was being called on every page load erroneously, and it wasn’t (and yet attest was being added to every page [confirmed by using print_r($_GET) on the theme]).

Not sure if this is the best way to go about this (please tell me if you see any issues/recommendations), but I figured it was worth mentioning what I ended up going with at the very least if others encounter this same issue & need a quick fix (also point it out so this issue might be resolved in future versions of this plugin).

I’d be open to giving it a try, and I’m sure more exposure for a potential fix is always a good thing as it might catch the author’s attention.

I too am experiencing this issue.

It’s able to write the cache & temp files perfectly fine, the paths seem to be correct, and the permissions appear to be normal. It’s just that the files unfortunately start to accumulate over time, and I have yet to figure this out :-/

That fixes it, but there was a syntax error in your str_replace (backslash needed to be doubled up).

str_replace('$','\\$',stripslashes($event->event_desc))

I see. Thanks for the heads up.

* = Network Activated

AdRotate
*Align RSS Images
Breadcrumb NavXT
Cleaner Gallery
Contact Form 7
FD Feedburner Plugin
Google Analytics Dashboard
Google XML Sitemaps
IntenseDebate
jQuery Collapse-O-Matic
Mass Page Maker
Media Categories
*Multisite User Management
Page Links To
Platinum SEO Pack
Really Simple CAPTCHA
Shortcode Exec PHP
TinyMCE Advanced
Unattach
*Use Google Libraries
*User Role Editor
Wordpress Download Monitor
*WP-reCAPTCHA
*WP Activate Users
*WP Minify
*WP Security Scan
*WP Super Cache

lcool,

3.1.4 just came out… it still has this issue. I don’t know how that’s possible. I updated to 3.1.4 & re-instated this patch.

I can’t thank you enough for making this plugin as flexible as it is while keeping the high-level aspects as simple as they are.

I’ve just created a custom verification/validation function that prevents free email providers to be used for the email field, and I thought I’d share. BTW, this is a fully working example, but you can repurpose/modify it to do anything else.

// Add custom validation for CF7 form fields
function is_company_email($email){ // Check against list of common public email providers & return true if the email provided *doesn't* match one of them
	if(
		preg_match('/@gmail.com/i', $email) ||
		preg_match('/@hotmail.com/i', $email) ||
		preg_match('/@live.com/i', $email) ||
		preg_match('/@msn.com/i', $email) ||
		preg_match('/@aol.com/i', $email) ||
		preg_match('/@yahoo.com/i', $email) ||
		preg_match('/@inbox.com/i', $email) ||
		preg_match('/@gmx.com/i', $email) ||
		preg_match('/@me.com/i', $email)
	){
		return false; // It's a publicly available email address
	}else{
		return true; // It's probably a company email address
	}
}
function custom_email_validation_filter($result,$tag){
	$type = $tag['type'];
	$name = $tag['name'];
	if($name == 'company-email'){ // Only apply to fields with the form field name of "company-email"
		$the_value = $_POST[$name];
		if(!is_company_email($the_value)){ // Isn't a company email address (it matched the list of free email providers)
			$result['valid'] = false;
			$result['reason'][$name] = 'You need to provide an email address that isn\'t hosted by a free provider.<br />Please contact us directly if this isn\'t possible.';
		}
	}
	return $result;
}
add_filter('wpcf7_validate_email','custom_email_validation_filter', 10, 2); // Email field
add_filter('wpcf7_validate_email*', 'custom_email_validation_filter', 10, 2); // Req. Email field

Thanks again, and I hope others might find this helpful.