reset password link doesn't work

Do you really need to reset the password because you cannot login ?

If not please login and disable the iTSec plugin “Hide Backend” feature.
Then retry resetting the password.

Let us know the result. I just want to make sure the password reset issue is caused by the iTSec plugin “Hide Backend” feature.
It could also be a generic WP issue.

dwinden

Hi dwinden

OK no I was able to login (it was just my client was having trouble so I just went through the process to replicate the issue). So I just logged in and deactivated Hide Back end. When I do this, go through the lost password process, the link from the email opens up with the correct change password screen.

So looks like it is the hide back end causing this.

Ok, thanks for the feedback.

hmm, weird. It works just fine in my test environment …
So I feel like we are missing an important piece of the puzzle …

You probably tested the link from a newly generated email (which is fine).

I wonder what happens when you test using the link from a previously generated email … (don’t actually use the link from an old email since the reset code will by now be overwritten in the database invalidating that old reset code).

So what I’m saying is generate a new email with link while the “Hide Backend” feature is enabled, confirm the link in that email does not work properly, then disable the “Hide Backend” feature and finally retry the link from that same email.

The result of the above described test is important to know because if we can determin that the first part (creating the link for the email and setting the reset code in the database) is done properly while “Hide Backend” feature is enabled we only need to focus on the link not working while “Hide Backend” feature is enabled.

Password reset is a faily complicated multi step process. So anything we can rule out brings us a step closer to a solution.

dwinden

will test this shortly and report back

hmm, well, I just tired again (with hide backend enabled) and the link now works!

Could it be to do with whitelisting my IP which I have done since trying this last night and encountering the error. I suspect the client may have also been locked out due to too many attempts at the time she encountered this.

Ah, oh that’s interesting because I was anticipating on a slight chance that this could happen …

It could be that even though the “Hide Backend” feature was enabled it was not fully operational the way it should be.

When enabling the “Hide Backend” feature 2 changes take place:

1. The Hide Backend feature boolean flag is set to 1 (yes) in the database. Once set it can only be changed by knowingly disabling the Hide Backend checkbox.
So we can safely assume this was in place at the time the issue occurred.

2. Also the following lines are added to the .htaccess file in the root of the WP install:

# BEGIN Hide Backend
# Rules to hide the dashboard
RewriteRule ^(/wordpress/)?newslug/?$ /wordpress/wp-login.php [QSA,L]
# END Hide Backend

(This is taken from my test env where I have WP installed in a “wordpress” subdir).

The .htaccess file is known to be the weak link. It can be altered while the iTSec plugin is completely unaware of this.

And apart from the “Hide Backend” feature there are numerous other iTSec plugin features (settings) that also write to the .htaccess file.

So when you just disable\enable the “Hide Backend” feature and click on the “Save All Changes” button the iTSec plugin will always write all lines for all settings to the .htaccess file (and wp-config.php).

What I’m trying to say is that the root cause of the issue could very well have been an incorrectly configured .htaccess (or even wp-config.php) file. Enabling\disabling the “Hide Backend” feature has possibly straightened out the .htaccess (and wp-config.php) file.

It would be interesting to compare the content of the current .htaccess file with a recent backup copy (if available).

Without a full understanding of what exactly caused the issue there is always a possibility that the issue returns sooner or later.

You can also post the content of the current .htaccess (after making some changes to obscure sensible data) so I can take a look at it. It will give me an idea of the settings activated in the iTSec plugin.

But even more important is how the previous .htaccess file looked like.

So even though we got closer to the cause we still haven’t found that important piece of the puzzle I was talking about earlier. Would love to find it though.

Oh and I don’t think the whitelisting plays any role in this. If I understand correctly you were able to reproduce the issue even while being whitelisted.

dwinden

OK great thanks dwinden, this particular client is hosted with WP Engine so I don’t have backupbuddy backups of the site as I would normally do. WP Engine do daily backups though so I will try and get yesterday’s htaccess. Here is todays:

Could I send you the .htaccess files privately? Maybe via the pro support on iThemes? I think I can change any sensitive bits but would rather have peice of mind just in case.

Ok.
I think you should know I’m not an iThemes employee. But many people make the same mistake. Rest assured any data provided is safe with me.
Just read some of my posts in other topics here in the forum and you’ll get the picture.

You can email me at [ redacted, support is not offered via email, Skype, IM etc. only in the forums ]. Based in The Netherlands.

dwinden

Ah sorry! Have emailed you. Thanks very much.

Ok, I digitally compared the content of the 2 .htaccess files and they turn out to be identical indeed …

So thats a dead end I guess. Hmmm really thought we were getting closer.
It’s hard to find any logic in this.

There is one thing I noticed immediately in the .htaccess file(s) and that is that your secret login slug is case sensitive … XXXXxxxxxxx.

I tried making mine in my test env case sensitive but I can’t. The Hide Backend converts it to lowercase every time I try to save it.

So in the current iTSec plugin release (4.6.12) it’s impossible to specify and use a case sensitive secret login slug …

So are you using the latest iTSec plugin release (4.6.12) ? If not what version are you using ? And what is the history of this install ?
Was the iTSec plugin installed recently or has it been there for like a year (or longer). The reason why I ask is because perhaps the issue was a quirck in the database related to old upgrade(s) of the plugin.
It could also explain the origin of the case sensitive login slug.
Even though it seems to work I would personally be more confident when using a full lowercase secret login slug.

Too bad the issue seems to be resolved because the next step would have been to debug the code. I had already identified and analyzed the piece of code (in wp-login.php file) where the reset password is handled.
Should the issue return keep in mind debugging is still an option.

dwinden

Never mind my comments on the case sensitive secret login slug.
Posted that while watching a soccer game on TV …
So wasn’t thinking clearly …

I guess the secret login slug is case sensitive because you obscured it …

Correct me if I’m wrong.

dwinden

I had the same issue
Installed ithemes security plugin
& got locked out

My host had to use a back up & change the theme & I managed to get back in – I still havent figured it out yet & dont wont to log out of my site till its sorted just in case – I hope there is a fix

@thefloorsweeper
I’m sorry to hear you have a similar issue. However as per the forum rules\guidelines please start your own topic.

dwinden

Hi dwinden,

yes you’re correct, I obscured the login, my real login url is all lowercase.

Ok fair enough.

Would still be interested to hear the answers to these questions:

So are you using the latest iTSec plugin release (4.6.12) ? If not what version are you using ? And what is the history of this install ?
Was the iTSec plugin installed recently or has it been there for like a year (or longer) ?

Just to be prepared when the issue reoccurs …

dwinden