Let me see if one of our developers has any ideas.
-Brian
I’ve taken a brief look at the code you pasted and I don’t see why we wouldn’t log this. It’s just submitting a form to the normal WordPress login mechanism. Are you sure you’re signing into the correct site?
Does Wordfence block you if you fail enough login attempts? You can test this using Tor or a proxy so that you don’t block your own IP address.
Mark.
Thread Starter
Ryder
(@hyflex)
Hi,
Yes it’s signing into the right site and the login works… but nope it doesn’t even trigger failed login attempts.
Thread Starter
Ryder
(@hyflex)
Any ideas?
I can give you test website access if you would like (drop me an email or something so I can contact you) to allow you to test…
Thread Starter
Ryder
(@hyflex)
It appears that the function that Wishlist use is hooking at a higher priority level than Wordfence that’s why it’s not capturing the login…
Any idea to fix it?
The priority level of the hooks should not matter, unless the Wishlist plugin is blocking failed attempts without letting the rest of the WordPress login process complete.
Since that is a premium plugin, their support staff might be able to tell you what happens when a login fails — if they have their own brute force protection, it could easily cause a conflict, but they might have a way to turn it off to let Wordfence handle it instead.
Thread Starter
Ryder
(@hyflex)
Wishlist said:
I went ahead and updated the priority of the login function of WL Login 2.0 plugin to 11 (default is 10) so the Wordfence hook should take effect first before us. Assuming they don’t have a redirect function on their code, their email notification should be run first and then proceed to our login function.
Any comments, because it didn’t work.
Are you running any other security plugins on the same site? If so, can you try turning them off and checking if the admin login notices will work again?
Or does Wishlist include any login security features?
If another plugin blocks the connection before Wordfence logs/checks it, it might deny the user access before Wordfence would log it.
I don’t think Wishlist should change its priority any further — if it runs after Wordfence, that might make it block logins that shouldn’t be blocked.
Wordfence uses a priority of “99” for this hook, to make sure it can do its work after other login-related plugins are already done, but before the login process is done. For example, if another plugin allows users to log in with their email address instead of username, that needs to happen before Wordfence checks it.
Thread Starter
Ryder
(@hyflex)
Hi,
I’m also running BPS Security but disabling that doesn’t change anything. As far as I can see there isn’t any security in Wishlist that should prevent this.
I also have a plugin that allows e-mail login but again that isn’t causing the problem.
I can give you access to a testing copy if you wish, just drop me a message/email so I can forward you some details and you can have a look. As you’re familiar with your own plugin you might go “oh it’s this!” straight away 😛
The problem is going to come down to the actual Hook being used itself and changing the priority would not make any difference. Example: BPS uses this login hook filter add_filter('authenticate', 'bpspro_wp_authenticate_username_password', 20, 3); to process logins and this particular hook filter can only be used by 1 plugin at a time to process logins. Most WP hooks – actions and filters – can be shared/used by any/all plugins at the same time, but not the authenticate hook (to process logins). A simply analogy would be this: only 1 person can drive a car at the same time. So basically the only option left is to choose to allow 1 plugin to use this hook to process logins and turn off the other plugin’s feature that is trying to use this hook to process logins.
Interesting Note: The BPS Log All Account Logins feature does partially work using the authenticate hook at the same time as other plugins, but login processing itself is still overridden.
You should always choose to let a member/membership plugin or theme handle login processing since typically they do many other things with logins besides just login processing.
Thread Starter
Ryder
(@hyflex)
Wishlist said the following in regards to Wordfence:
Open up wordfence/lib/wordfenceClass.php and then edit this line of code
add_action(‘wp_login’,’wordfence::loginAction’);
and add a priority so it would like like this.
add_action(‘wp_login’,’wordfence::loginAction’, 1);
I did this and it fixes Wordfence for the sidebar login form for both Wishlist’s default widget and their Wishlist Login 2.0 widget.
Is this the correct fix, who needs to change what to get it fixed? >_<
hmm guess Wordfence is not using the “authenticate” filter to process logins then and is instead using the “wp_login” hook, which can be shared by many different plugins at the same time and changing the priority for this particular hook does work fine. Probably the best solution would be for Wordfence to create a new DB option for this issue: ie option name: “Change Login Processing Priority” or even simpler “Wishlist Member Login Fix”.
Thread Starter
Ryder
(@hyflex)
Wordfence / WFBrian
Any chance of getting something added for WLM users or switching to using the authenticate filter rather than wp_login hook?
Thanks
Wordfence uses the authenticate filter and wp_login for different parts of its processing. Changing the priorities or moving some of the functions might have unintended consequences, so I wouldn’t recommend doing that manually. I can put in a request with the dev team to see if there is anything else that can be done.
Does Wishlist, by chance, redirect the user to another page upon login, instead of letting the regular WordPress login process finish completely?
Thread Starter
Ryder
(@hyflex)
Hi WFMattR,
Yes, Wishlist does have the ability to redirect on login, see: http://i.imgur.com/1C20N6o.png
I understand that it may have “unintended consequences”; that’s asked for something to be done for it because I’d rather not something act weird (I can give temporary access to my test site if need be) to help you change/fix it.
As far as I can see giving it a priority of 1 hasn’t made anything go wrong anywhere.
