There appears to be an authentication/session management issue where an existing user session remains active after the user's credentials are changed from another browser/session.
For example:
Log in to Nginx Proxy Manager as User A in Browser 1.
Keep Browser 1 logged in.
Open Browser 2 and log in using the same User A account.
From Browser 2, change User A's username/email and password.
Browser 1 is still logged in and can continue using the application without being asked to authenticate again.
The session in Browser 1 remains valid even though the user's credentials have been changed.
Expected behavior
Changing a user's password and/or username/email should invalidate existing authenticated sessions for that user, or otherwise require re-authentication.
For example, after changing the password from Browser 2, Browser 1 should receive an authentication/session error and be redirected to the login page.
A configurable session timeout would also be useful so that authenticated sessions cannot remain valid indefinitely.
Actual behavior
The existing session in Browser 1 remains active after the user's password and username/email have been changed from another browser.
The user is not prompted to log in again, and the existing session continues to have access to the account.
Security concern
This could be problematic if an account is compromised or a user's credentials are changed as part of an account recovery/security action.
For example:
An administrator changes a user's password because the account may have been compromised.
The previous session/token may still be valid.
Anyone who has access to that previous browser/session can potentially continue accessing the account despite the password having been changed.
Changing the password should ideally revoke previously issued sessions/tokens.
There appears to be an authentication/session management issue where an existing user session remains active after the user's credentials are changed from another browser/session.
For example:
Log in to Nginx Proxy Manager as User A in Browser 1.
Keep Browser 1 logged in.
Open Browser 2 and log in using the same User A account.
From Browser 2, change User A's username/email and password.
Browser 1 is still logged in and can continue using the application without being asked to authenticate again.
The session in Browser 1 remains valid even though the user's credentials have been changed.
Expected behavior
Changing a user's password and/or username/email should invalidate existing authenticated sessions for that user, or otherwise require re-authentication.
For example, after changing the password from Browser 2, Browser 1 should receive an authentication/session error and be redirected to the login page.
A configurable session timeout would also be useful so that authenticated sessions cannot remain valid indefinitely.
Actual behavior
The existing session in Browser 1 remains active after the user's password and username/email have been changed from another browser.
The user is not prompted to log in again, and the existing session continues to have access to the account.
Security concern
This could be problematic if an account is compromised or a user's credentials are changed as part of an account recovery/security action.
For example:
An administrator changes a user's password because the account may have been compromised.
The previous session/token may still be valid.
Anyone who has access to that previous browser/session can potentially continue accessing the account despite the password having been changed.
Changing the password should ideally revoke previously issued sessions/tokens.