During the password change process, the current session is terminated, and a new session begins. While I don't agree with that, it's how WordPress 4.0~6.2 appear to work.
The result of this is that the current sessions metadata is discarded, and the current session becomes a non-2fa session. This also means that the user must revalidate to change settings (even if they just logged in).
Possibly, the hook should be used outside of the login process with a check to sync over metadata from the current session to the newly generated session if the user is the same.
Describe the bug
During the password change process, the current session is terminated, and a new session begins. While I don't agree with that, it's how WordPress 4.0~6.2 appear to work.
The result of this is that the current sessions metadata is discarded, and the current session becomes a non-2fa session. This also means that the user must revalidate to change settings (even if they just logged in).
This is partially caused by Two-Factor only using the
attach_session_informationhook during the 2fa checks: https://github.com/WordPress/two-factor/blob/654ebb75024c21c116b4155e7254e143c9f64413/class-two-factor-core.php#L1291-L1302Possibly, the hook should be used outside of the login process with a check to sync over metadata from the current session to the newly generated session if the user is the same.
See https://core.trac.wordpress.org/ticket/58427 See https://github.com/WordPress/wporg-two-factor/issues/191
Per the upstream core ticket, IMHO this is a core bug, but one that Two-Factor probably has to work around.
Steps to Reproduce
Screenshots, screen recording, code snippet
Uploading Screen Recording 2023-05-30 at 2.29.01 pm.mov…
https://github.com/WordPress/two-factor/assets/767313/a9ac3603-2dda-4270-b8d8-6e427b61857e
Environment information
Please confirm that you have searched existing issues in this repository.
Yes
Please confirm that you have tested with all plugins deactivated except Two-Factor.
Yes