richardsaunders

Is there an update on this item or any updates at all?

We use revisions for monitoring and logging changes across the site through produced reports, which now aren’t available anymore for Table based changes due to the above mentioned issue.

• This reply was modified 5 years, 5 months ago by richardsaunders.

If I uncover such a method I will divulge it here.

The regression I mentioned above is to allow users that are locked out and cannot remove Two Factor Authentication from production level environments the ability to access their sites again, as this essentially locks them out until they deactivate the plugin manually via database flags, manual file replacement, etc.

Ideally the captcha wouldn’t persist to additional screens that do not contain the actual login form, is there simply no plans to support plugins that require Two Factor Authentication or post login screen criteria of any kind?

I’ll be happy to use something else if this is the approach.

By replacing the following lines in the login-nocaptcha.php in the authenticate function from:

update_option(‘login_nocaptcha_working’, true);
return new WP_Error(‘denied’, __(‘Please check the ReCaptcha box.’,’login_nocaptcha’));

to the previous:

update_option(‘login_nocaptcha_working’, false);
update_option(‘login_nocaptcha_google_error’, ‘error’);
update_option(‘login_nocaptcha_error’, sprintf(__(‘Login NoCaptcha is not working. Please check your settings.’, ‘login_nocaptcha’), ‘options-general.php?page=login-recaptcha/admin.php’).’ ‘.__(‘There was no response from Google.’,’login_nocaptcha’) );
return $user; //no response from Google

I was able to get control back to my sites.

This is also not compatible with Duo Authentication Plugin as well.

I would argue that because this issue compromises any follow up screen authentication to the Logins for sites that it should be the responsibility of this plugin owner as opposed to others, as it seems that 1.2 has introduced quite a few issues with the hardening.