User returned to default login URL after failed attempt

The redirect the second time is more concerning than the first part. The first one happens because the redirect doesn’t happen if the user is logged in – are you sure you’re logged out completely when testing that first issue?

If so, I’ll need to revisit some of the conditionals.

BTW, I always test this on a non-logged in browser to ensure I don’t have an open session and am skipping my own redirect code.

Retested failed login, followed by correct login…

• Cleared cookies.
• Logged in using user & password that would fail (random keys).
• Login failed, automatically returned to login page WITHOUT tokens in URL.
• Logged in using correct user & password.
• Stealth Login Page failure page (404 in my case).

In this case, please use my site contact form to provide me with your SLP login URL and create a basic user for me to try to login with – Subscriber or Author is fine.

I’m doing this to troubleshoot the plugin with our setup to make the plugin better, but anyone reading this later, this isn’t an open invitation to personally support everyone’s issues – this is very specific.

As requested, created a Subscriber account for you and emailed you the details via your website’s contact form. Thanks again.

I believe you asked whether I was using other plugins that might affect this. Yes, I am using the Better WP Security plugin, but I do not have that plugin’s Hide Backend feature enabled. I did use BWPS to rename the “wp-content” directory before enabling Stealth Login Page, but while debugging this issue, named it back to “wp-content”; did not resolve this issue. Any other ideas? Thanks.

Before you got locked out – did your custom URL display it properly? The display of the Custom URL and the accompanying e-mail it sends when you check the box will tell us if it’s correct.

You can view the settings in the SQL if you look in the wp-options table for “slp-“

I was just able to login to your dashboard using your link and login provided. I wasn’t forwarded. Try another browser to see if you have cookies interfering.

Hey Jesse. Thanks for picking this back up, despite my delay. My issue isn’t a lockout one – it’s about a failed login attempt at the correct login URL (the Stealth login page) taking the user back to the default login URL (WordPress default). My concern is that if the user re-attempts logging in using correct credentials from this second page (the default one), login will fail anyway and they will be confused.

Doh! My bad. You’d think that second glass of Mt. Dew would have prevented that mistake…

I see the concern now and verified that it does happen. The issue is that is the function that blocks bots. If the request does not come from the custom URL, then it is redirected because if a bot guesses incorrectly and can stay there, then the plugin is useless for bots.

All I can say at the moment is that it needs to be a valid login attempt unless I can sort out how to handle a failed login from the custom URL to redirect to the custom URL again. That’s a deeply embedded function of the core, so I’m not sure as a padawan learner how to sort that out and maintain security.

Perhaps when I release v4.0, I can lax this a bit because I intend on doing deeper bot detection. If bots are 99.99% taken care of, I think this can be modified to not behave this way.

Haha, no worries. Not even Mt. Dew can fix everything.

Ok, so we’re on the same page. Sounds good. So far, I’ve been very happy with this plugin. Thanks for looking into this feature.

My pleasure. I’ll mark this as resolved for the sake of there not being any solution at this time – v4 should address this to some extent or completely.