The redirection has nothing to do with those fields, which is my bad – this redirection is solely associated with not filling in the correct auth code.
If you are using the old method, the redirection had nothing to do with a successful or not login – solely on the correct or incorrect login URL.
This is primarily targeted at bots and I’m taking steps to make a comprehensive security plugin one feature at a time – then it will all come together based on what’s working and not.
Does that clear it up?
From my testing:
1. If someone/bot enters a VALID username and an incorrect password, they are redirected.
2. If someone/bot enters a VALID username, a correct password and an incorrect Authorization code, they are redirected.
3. If someone/bot enters a username that DOESN’T exist and an incorrect password they get the “ERROR: Invalid username. Lost your password?” error message and are NOT redirected.
This seems a little illogical to me. After all, most bots start off by trying to brute force “admin” as a username. As no one with any sense uses admin as a username anyway, this means that the bot will get the error message and continue trying to attack the login page as per the third case above.
So the login hasn’t really been “Stealthed” like in previous versions. Instead, it’s pretty much like we now need 2 passwords to login instead of one.
Surely it makes more sense to “bounce” a bot off our site to somewhere else (thus reducing the load on our site) if the bot uses a username that doesn’t exist or an incorrect password?
Thanks,
Kirstie.
I am also seeing this issue. When I enter a legitimate username with a bad password and bad auth code I don’t get redirected. I actually just get an incorrect username and password message. Is this how it’s supposed to work?
Thanks a lot.
The redirect is based on the auth field. I’ll have to re-work things, it’d appear.
Please revert to 3.0.0 if this is too bothersome and I do agree that stealth is gone, but it was changed for reasons in the threads that I’ve stickied in the forums.
I’ll add an option to use either method OR you can simply clear out the auth field in the settings and your old settings should still be in the database unless you deactivated and deleted 3.0.0 before updating.
I’m slowly adding different methods so people can choose and this method was strictly because of WP 3.6 heartbeat API.
Thanks Jesse. As far as I can see you can’t actually clear out the auth field because when you try to save you get a js validation error. Am I missing something there?
I went ahead and downgraded our sites to 3.0.
Thanks for the quick response.
Jonathan
Darn, no. I did put that in place so people couldn’t save with blank fields. I forgot about that. You can go into SQL and clear that out of the settings, but stick with 3.0.0 until WP 3.6 comes out and I’ll see how fast I can have 4.1.0 out.
Thanks Jesse. You did an awesome job with the plugin. I think people are just frustrated because the simplicity of v3 of the plugin worked so well and required minimal effort on their part. I’m looking forward to seeing the next iteration.
Jonathan
I couldn’t agree more with Jonathan.
Jesse, v3 was groundbreaking and an absolutely brilliant plugin – both in terms of concept and ease of use.
Plus I loved the idea of redirecting bots and attackers instantly off my site to somewhere else.
As you advise, I’ll stick with v3 for the moment.
Thanks again 😉
Noted. It is coming back. ASAP.
I clearly made an error in judgement in preparing for WP 3.6 (dropped yesterday, so go update after making a backup and see what happens when you sit idle in a post too long.
I will ensure I have several feature checkboxes, so I’m working out the UI in my head before I begin because I have so many full-site projects in my queue.
