WP-Members and Login with AJAX

I now have a problem with what appears to be a conflict between Login with Ajax and the BulletProof Security plugin which I recently installed. Users are unable to reset their passwords because when they click on “Get New Password” in the Login with Ajax widget it doesn’t load properly. It just “hangs” with the wheel going around incessantly.

I have deactivated BulletProof Security, but the problem still exists.

If I delete the plugin will that remove all the files that were created during its installation or will I have to try to isolate all of those files and delete them manually?

If 2 or more plugins have the same features/are doing the exact or similar things then you would want to choose which feature to use. If plugin features are doing the same or similar things then there is most likely going to be some sort of a conflict.

Thanks AITpro. Actually I deactivated Theme my Login and BulletProof Security (and a few others) just after I made that last post and the login conflict seems to have been resolved.

However I still have the issue of the login boxes. As I initially said I prefer the Login with Ajax sidebar widget, but I can’t seem to work out how to have it as the only login facility. The WP-Members login still appears in the body of the page but I don’t want the WP-Members login to appear at all. I want to deactivate that part of the plugin.

I love the user control that WP-Members give me with the site, but I would like to know if it is even possible for the plugin to work with the login box deactivated.

Hopefully someone will be able to steer me in the right direction.

already aware of BulletProof security as well as Theme my login, will check out WP-Memebers as well when time permits (please bear in mind it may take a couple of weeks due to time constraints)

btw, i check the support forum for the plugins themselves, not just the tags. hence my lack of reply.

You do not need to deactivate BPS to turn BPS Login Security Off. You can turn BPS Login Security Off on the BPS Login Security page. I believe that you can also turn TML Login Security Off too, but I am not totally sure about that.

Activate BPS again and check your BPS Security Log. If BPS is blocking something then you will see that error logged in the BPS Security Log. If you see an error logged then post it.

As of BPS .47.8 Security Logging / HTTP Error Logging has been added. If you are experiencing a possible plugin conflict or some other issue or problem on your website check the BPS Security Log tab page for any errors related to the issue/problem. Create a new Topic and post the error message that is related to the issue/problem.

If you think that BulletProof Security is causing a plugin conflict or any other issue on your website that is causing something not to work, then please use these steps below to take BulletProof Security out of the equation completely for testing. There is no need to deactivate BulletProof Security because it has a built-in Default Mode that allows you to put WordPress in a default state without deactivating BulletProof Security.

1. Make a backup of your .htaccess files using BulletProof Security built-in Backup.
2. Activate Default Mode on the Security Modes page.
3. Use the Delete wp-admin .htaccess feature on the Security Modes page.
4. If the issue/problem is related to Login Security turn Off Login Security on the Login Security & Monitoring page.
5. Test your plugin or theme.
6. Restore your .htaccess files using BulletProof Security built-in Restore.

To completely uninstall BulletProof Security you would do steps 2 and 3 above and then just delete the BulletProof Security plugin on the WP Plugins page.

@aitpro didn’t realize you were the author of BPS, thx for chipping in ??

will keep this in mind when testing BPS

@marcus – yep we are trying to follow more of a standard App model/method of built-in troubleshooting capability with error logging to make troubleshooting simpler/accurate/definite (ie no guesswork).

BPS does block admin-ajax.php by default so my guess is that if BPS is causing this issue then most likely it is because admin-ajax.php is being blocked. We have debated for a very long time whether or not to whitelist admin-ajax.php by default. Some folks want admin-ajax.php blocked by default so what we are planning on doing is something like this.

Admin notice w/usermeta Dismiss button – when a 403 error is triggered/logged due to admin-ajax.php being blocked then display an Admin notice w/dismiss button so that users can decide what they want to do next.

To whitelist admin-ajax.php in the wp-admin .htaccess file this skip/bypass rule can be added to the wp-admin .htaccess file.

# admin-ajax.php skip/bypass rule
RewriteCond %{REQUEST_URI} (admin-ajax\.php) [NC]
RewriteRule . - [S=2]

Troubleshooting tools are a great idea.

r.e. admin-ajax.php – My opinion – I would advocate profusely NOT blocking it by default, and warning users of the potential consequences on the setting page.

My other plugin, Events Manager uses admin-ajax.php heavily, and so does any plugin that follows the wp recommended way to use ajax.

https://codex.www.ads-software.com/AJAX_in_Plugins

Blocking it by default is asking for more frustrated users with plugin conflicts (for you and us) and more time troubleshooting ??

we don’t use admin-ajax.php here afaik but we may well resort to it too… some plugins have custom registration pages and so intercepting ajax calls at wp-login.php can cause problems when they redirect to the custom pages, or the form already points to the page which we don’t have ajax hooks for.

Yep, we completely understand the pitfalls of blocking admin-ajax.php generally by default. Another approach would be to create .htaccess conditions that look at/check for the typical attack/exploit/hacking patterns that we see regularly that are trying to exploit admin-ajax.php

ie

RewriteCond %{REQUEST_METHOD} ^POST
RewriteCond %{REQUEST_URI} X something with admin-ajax.php
RewriteCond %{HTTP_REFERER} !^.*add-your-domain-name-here.com.* [OR]
RewriteCond if hacker/spammer/dummy X is doing this
RewriteCond if hacker/spammer/dummy Y is doing this
RewriteCond if hacker/spammer/dummy Z is doing this

something along the lines of this BuddyPress Anti-spam registration code that stops/prevents over 45,000 spam registrations per month and saves us countless hours of cleaning up the mess these dummies make.

# BuddyPress Anti-Spam Registration
RewriteCond %{REQUEST_METHOD} ^POST
# only match the register page URI
RewriteCond %{REQUEST_URI} ^/register/$
# domain referer is better than IP - allows for subdomains
RewriteCond %{HTTP_REFERER} !^.*add-your-domain-name-here.com.* [OR]
# Blank or single hyphen user-agent spoofers or curl
RewriteCond %{HTTP_USER_AGENT} ^(|-?|curl)$ [NC,OR]
# HTTP request header
RewriteCond %{THE_REQUEST} HTTP/1\.0$
RewriteRule ^(.*)$ /spam-prevention [R=301,L]

What makes this difficult to do is the errors do not give away the exact method of attack since typically the attacks are not directly at admin-ajax.php, but instead are involving admin-ajax.php in the method of the attack/exploit. ??

Important NOTE: admin-ajax.php is very secure in itself. What would make the call or use of admin-ajax.php exploitable would of course depend on what a plugin or theme is doing after calling admin-ajax.php. So to be 100% technically correct admin-ajax.php in itself is not exploitable and it would be the code in a plugin or theme that would be the exploitable code.

Just saw an interesting attack on our BuddyPress Forum that involved admin-ajax.php and this serves as a neat example:

This only causes a temporary nuisance and of course does not go any further than that.
At the top left section of the BuddyPress site you will see the hackers code displayed during the attack. It is of course stripped out and is only a temporary nuisance.

hacker (or bonehead) posts javascript into the TinyMCE WYSIWYG editor, which creates a temporary nuisance.

targets: admin-ajax.php (vicariously), tinymce, BuddyPress and WordPress Admin bar.

@aitpro thx for your input

do you have a recommended constant or similar to check if BPS is loaded? I could just add a notice ot the LWA settings page advising them about this potential problem if both our plugins are active.

if it’s a setting issue then that could be the best approach.

You can do a standard WP “is plugin activated” check and also check for the “admin-ajax” string in the wp-admin .htaccess file w/ Admin Dismiss button.

function example_simple_active_plugin_check_with_dimiss_admin_notice() {
$plugin_var = 'bulletproof-security/bulletproof-security.php';
$return_var = in_array( $plugin_var, apply_filters('active_plugins', get_option('active_plugins')));
$filename = ABSPATH . 'wp-admin/.htaccess';
$check_string = @file_get_contents($filename);

	// Check if BPS plugin is active and the admin-ajax.php skip/bypass rule does not already exist in the wp-admin .htaccess file
	if ( $return_var == 1 && !strpos($check_string, "admin-ajax") ) { // 1 equals active plugin
		$text = '<div class="update-nag"><li><strong><font color="red">'.__('Your Message here with Dismiss button', 'bulletproof-security').'</font><br>'.__('To Dismiss this Notice click the Dismiss Notice link below. To Reset Dismiss Notices click the Reset/Recheck Dismiss Notices button on the S-Monitor page.', 'bulletproof-security').'<br><a href="index.php?bps_example_nag_ignore=0">'.__('Dismiss Notice', 'bulletproof-security').'</a></strong></li></div>';
		echo $text;
	}
}
add_action('admin_notices', 'example_simple_active_plugin_check_with_dimiss_admin_notice');

add_action('admin_init', 'bps_example_nag_ignore');

function bps_example_nag_ignore() {
global $current_user;
$user_id = $current_user->ID;

	if ( isset($_GET['bps_example_nag_ignore']) && '0' == $_GET['bps_example_nag_ignore'] ) {
		add_user_meta($user_id, 'bps_example_notice', 'true', true);
	}
}

And yes I dream in code – took 10 minutes to whip together. ??

If you want extra insurance add
current_user_can('manage_options');