dwinden
Forum Replies Created
-
If you require no further assistance please mark this topic as ‘resolved’.
(Bumping as sometimes new post emails are not send or received).dwinden
As posted earlier in this topic, if you value the Security Status feature more than anything listed as fixed or enhanced in the 5.2.0 Changelog, as a workaround simply download and install the previous (5.1.1) release.
It runs just as “smoothly” on the latest WordPress release (4.4.2) as the 5.2.0 release.dwinden
Yes, everything is ok. Simply monitor the website and see whether the issue persists or whether it is resolved.
In the meantime investigate alternative solutions for scheduling automatic database\website backups.
dwinden
I noticed there are another 4 plugin files where there is an action added to the wp_login hook.
core\modules\brute-force\class-itsec-brute-force.php:
add_action( ‘wp_login’, array( $this, ‘wp_login’ ), 10, 2 );
public function wp_login( $username, $user = null ) {
…
}core\modules\ipcheck\class-itsec-ipcheck.php:
add_action( ‘wp_login’, array( $this, ‘wp_login’ ), 10, 2 );
public function wp_login() {
…
}pro\password\class-itsec-password.php:
add_action( ‘wp_login’, array( $this, ‘wp_login’ ), 10, 2 );
public function wp_login( $username, $user = null ) {
…
}pro\user-logging\class-itsec-user-logging.php:
add_action( ‘wp_login’, array( $this, ‘wp_login’ ) );
public function wp_login( $user_login ) {
…
}I was surprised to see that in 2 cases the callback function is defined with $user = null as second argument … so those entries seem to be fine.
However the other two (in blockquotes) seem to be inconsistent.dwinden
Disable any enabled setting one after another in the System Tweaks section of the iTSec plugin Settings page.
dwinden
Indeed it looks like it’s either no parameters or 2 parameters (required).
You could run an automated search through all *.php files for do_action( ‘wp_login’, in the env reporting the warning.
This way you might be able to spot any incorrect do_action(‘wp_login’) call(s).There seems to be only 1 occurrence in WordPress core:
wp-includes\user.php: do_action( ‘wp_login’, $user->user_login, $user );
dwinden
(Thinking out loud here …)
I think I get your point but isn’t this also an attempt to fix a possibly incorrect/incomplete do_action(‘wp_login’) call ?In other words could it be the warning is generated because there is only one parameter passed to a do_action(‘wp_login’) call ?
eg: do_action( ‘wp_login’, $user_login );
while it should be:
do_action( ‘wp_login’, $user_login, $user );
Just wondering …
dwinden
I’m happy to hear you were able to resolve this mystery.
The explanation though doesn’t make any sense to me.
I tested after enabling SSL for Dashboard only but I’m still unable to reproduce the issue.
Never mind, I don’t need to understand everything.I guess this topic can be marked as ‘resolved’ 😉
dwinden
Just another thought …
Could this be a problem because the URL of dashboard in the top menu is “domain.com/wp-admin/” instead of “www.domain.com/wp-admin/” ?dwinden
As soon as you click on ANY ‘Save All Changes’ button on the Settings page the iTSec plugin will write ALL changes/rules again to the .htaccess file.
So if you had problems with some rules added to the .htaccess file by the plugin and you decided to manually replace the .htaccess file with a different\working copy it would make the .htaccess file temporarily out of sync with the iTSec plugin settings.
Instead in such problem situations the best procedure is to pinpoint which rules in the .htaccess file are causing problems and then disable the corresponding iTSec plugin feature. This will ensure only the problematic rules in the .htaccess are removed and the .htaccess file content stays in sync with the iTSec plugin settings.
Anyway I tested your scenario and I’m unable to reproduce the issue.
So it looks like it is a specific issue in your env.
Possibly caused by manually replacing the .htaccess file with a different copy. But there may also be a different yet unknown reason why this issue occurs.dwinden
And what URL do you see on the frontend behind the dashboard option in the top menu ?
Is it using the correct “www.domain.com/wp-admin/” URL ?
What happens when you use the browser back button ?
dwinden
I think the login=failed url parameter is a customization … It’s not a standard WP login page URL parameter.
Make it easier for yourself. Take 1 step at the time.
First make it work while not using a different login slug.
Then take the next step and change the login slug.Use the wp_login_failed action hook to redirect to the homepage upon a failed login attempt.
Only if changing the login slug breaks the wp_login_failed action hook solution then this is an iTSec plugin issue …
dwinden