This doesnt seem right to me. If a user request a password reset then they should use the reset mechanism

This doesnt seem right to. If a user request a password reset then they should use the reset mechanism

Yes, there is no issue if they use the reset mechanism, it will still work properly. But if in any case the user is able to recover his password and uses it to login instead then the password reset should be revoked in my opinion and also the activated state in the admin panel should be green instead of red like it is now.

My 2c is that this is solving a problem that doesn't exist and potentially introduces a security vulnerability

My 2c is that this is solving a problem that doesn't exist and potentially introduces a security vulnerability

I do agree, there is no issue from a user's point of view, because they can log in as usual without any issues, but the password reset remains active even if the user remembers his password and it is never updated in the backend that the account is activated.

According to my opinion any security vulnerability is greatly reduced due to this change happening only when the user logs in again using the old password and the match is successful.

Like in this case, the user can login as usual but backend still shows the account as non-active.

I am not going to explain the security issue inn public

If a user started the password reset procedure, the reset procedure should be finished. Whether the user remembered the password is irrelevant if you ask me.

If a user started the password reset procedure, the reset procedure should be finished. Whether the user remembered the password is irrelevant if you ask me.

I agree, Ideally this should be the case. Maybe something else can be done if the user happens to remember the password after resetting so that it is updated accordingly in the backend.

ah - I was under the impression that when the password request was set then the old password doesnt work anymore. I now understand that the account is still enabled and that only the activated flag is unset.

So for me that is the bug. When a password reset is requested the old password should not work and the only thing a user can do is to complete the reset process

ah - I was under the impression that when the password request was set then the old password doesnt work anymore. I now understand that the account is still enabled and that only the activated flag is unset.

So for me that is the bug. When a password reset is requested the old password should not work and the only thing a user can do is to complete the reset process

Made changes to address this change, now the user gets a warning of username and password do not match when they try to login using their old password and resetting the password the normal way is working.

Please do not fix this way !

We are trying to fix a not so common problem
and we are introducing a really bad issue

Read below what the current code change of this PR is doing

• someone (not me) uses my email to request a password reset

i can no longer login, instead i am forced to go to my email box and find email reset request
(or i create a new reset email if i had deleted that email thinking it is spam / scam)

ok i complete i have reset my password and i can login now

but then someone (not me) uses my email (again) to request a password reset
i can not login again

IMO this needs to be behind an option if this is going to be accepted. I can't think of too many platforms that arbitrarily lock out your account if you requested a password reset that force you to finish that request before regaining access. Plus, as mentioned above, a feature like this is rather easily subjected to spam or someone just being a pain in the butt and misusing it to annoy people by constantly forcing them to change their passwords.

I'm against this. whats wrong with you first version?
f872f0a + fixes

simple removing the reset token?

Why does the reset token need to be wiped out on a successful login? Realistically, those tokens should have a timestamp so they aren't usable beyond a short period of time (say, 24 hours).

Also, the fact that the reset token is being stored in the same column as the activation token is so many levels of wrong, I'm gonna need more coffee to unsee this problem.

my reason is that the reset token isn't valid for ever and yes the fields are wrong^^

my reason is that the reset token isn't valid for ever

And that's where the timestamp comes into play. There's a reason I did timestamps for the com_privacy request tokens.

timestamp invalidation is maybe better. All PR to fix is are welcome^^

Why does the reset token need to be wiped out on a successful login? Realistically, those tokens should have a timestamp so they aren't usable beyond a short period of time (say, 24 hours).

Also, the fact that the reset token is being stored in the same column as the activation token is so many levels of wrong, I'm gonna need more coffee to unsee this problem.

Reset token was wiped out in my commit on successful login to tackle the issue as in the issue, because if its not wiped out it still shows up in the backend that the user account is not activated

Reset token was wiped out in my commit on successful login to tackle the issue as in the issue, because if its not wiped out it still shows up in the backend that the user account is not activated

My point is the architecture is still flawed.

• A reset token is not an activation token
• A user requesting a password reset should NEVER equate to a user not having activated their account

Reset token was wiped out in my commit on successful login to tackle the issue as in the issue, because if its not wiped out it still shows up in the backend that the user account is not activated

My point is the architecture is still flawed.

• A reset token is not an activation token
• A user requesting a password reset should NEVER equate to a user not having activated their account

resetToken is now a new field and separate from activation. Thus fixing the above two concerns.

@mbabker @ggppdk @brianteeman Please check.

I think you should rebase on J 4.0. Also the expire variant mentioned by michael is better then removing a reset token on success.

I think you should rebase on J 4.0. Also the expire variant mentioned by michael is better then removing a reset token on success.

I think in most sites the reset token is removed after resetting the password successfully. Expiring the reset token after sometime is a good idea too.

I think you should rebase on J 4.0. Also the expire variant mentioned by michael is better then removing a reset token on success.

Added a token expire after 3 days check.

@Arpit-24 please close this PR as its rebased for J4.

Closing this one. See #24461