Summary
I'm seeing a persistent login/session issue in service where some users cannot recover access from a normal browser profile after failed login attempts, password reset/change, or switching users.
The same account usually works from an incognito/private browser window, which suggests the account itself is valid and the issue is related to stale browser authentication state, stale cookies, localStorage, or session handling.
This has been observed with more than one user/account and on more than one computer/browser profile.
Environment
- Browser behavior:
- Normal browser profile: login/session remains stuck or does not recover
- Incognito/private mode: login works
- Affected accounts observed:
- Admin attempted to clear login lockout from the user management UI.
What happened
- A user had multiple failed login attempts or needed password recovery.
- Admin updated/reset the user password.
- Admin used the "clear login lockout" option in the user management UI.
- The user still could not access from the normal browser profile.
- The same user could access from an incognito/private window.
- A similar behavior was also observed with another user on another computer/browser profile.
Expected behavior
After the password is corrected and the login lockout is cleared, the user should be able to log in normally from the same browser profile.
Also, when switching users or when a session expires/fails validation, the UI should fully clear the old authentication state and allow a clean login.
Actual behavior
The normal browser profile appears to remain stuck with an old authentication/session state.
In some captures, instead of seeing a fresh login attempt for the affected user, /api/auth/verify keeps validating another already-authenticated user/session.
Sanitized example:
[AuthAPI] Handling GET /api/auth/verify request
[AuthAPI] Authentication successful for user: OLD_USER (role: viewer/admin)
In these captures, there was no clear POST /api/auth/login attempt for the affected user, and no clear rate-limited, allowed_login_cidrs, unauthorized, or forbidden event for the affected username.
Troubleshooting already attempted
-
Updated/pulled the latest Docker image.
-
Restarted Docker Compose services.
-
Reset/updated the affected user password.
-
Used "clear login lockout" from the admin UI.
-
Tested incognito/private browsing successfully.
-
Monitored logs with:
docker compose logs -f lightnvr | egrep -i "POST /api/auth/login|GET /api/auth/verify|login failed|rate-limited|allowed_login_cidrs|unauthorized|forbidden|session"
Possible cause
This looks like a stale client-side auth/session state issue.
The browser may keep an old session cookie or localStorage state, and the UI may not fully clear it before presenting or retrying the login flow.
Because the session cookie is server-managed/HttpOnly, frontend-only cleanup may not be enough in all cases.
Suggested fix
Please consider improving the logout/session-reset flow:
- Ensure
/logout clears all authentication-related cookies server-side.
- Ensure stale/expired sessions are cleared before showing the login page.
- Provide a reliable "switch user" or "force logout" flow.
- Clear or invalidate old
session, auth, and trusted_device states when appropriate.
- On
/api/auth/verify failure or login page access, consider forcing a backend-side auth cleanup.
- Optionally use a dedicated endpoint to clear stale auth state before login.
Summary
I'm seeing a persistent login/session issue in service where some users cannot recover access from a normal browser profile after failed login attempts, password reset/change, or switching users.
The same account usually works from an incognito/private browser window, which suggests the account itself is valid and the issue is related to stale browser authentication state, stale cookies, localStorage, or session handling.
This has been observed with more than one user/account and on more than one computer/browser profile.
Environment
What happened
Expected behavior
After the password is corrected and the login lockout is cleared, the user should be able to log in normally from the same browser profile.
Also, when switching users or when a session expires/fails validation, the UI should fully clear the old authentication state and allow a clean login.
Actual behavior
The normal browser profile appears to remain stuck with an old authentication/session state.
In some captures, instead of seeing a fresh login attempt for the affected user,
/api/auth/verifykeeps validating another already-authenticated user/session.Sanitized example:
In these captures, there was no clear
POST /api/auth/loginattempt for the affected user, and no clearrate-limited,allowed_login_cidrs,unauthorized, orforbiddenevent for the affected username.Troubleshooting already attempted
Updated/pulled the latest Docker image.
Restarted Docker Compose services.
Reset/updated the affected user password.
Used "clear login lockout" from the admin UI.
Tested incognito/private browsing successfully.
Monitored logs with:
docker compose logs -f lightnvr | egrep -i "POST /api/auth/login|GET /api/auth/verify|login failed|rate-limited|allowed_login_cidrs|unauthorized|forbidden|session"
Possible cause
This looks like a stale client-side auth/session state issue.
The browser may keep an old session cookie or localStorage state, and the UI may not fully clear it before presenting or retrying the login flow.
Because the session cookie is server-managed/HttpOnly, frontend-only cleanup may not be enough in all cases.
Suggested fix
Please consider improving the logout/session-reset flow:
/logoutclears all authentication-related cookies server-side.session,auth, andtrusted_devicestates when appropriate./api/auth/verifyfailure or login page access, consider forcing a backend-side auth cleanup.