Provide the Bytebase version you are using

3.23.0

Describe the bug

When Bytebase is accessed over plain HTTP (non-secure context, e.g. http://:8080 or behind an http-only reverse proxy), the web token auto-refresh is completely broken. After the access token expires, the client fails to refresh it and the user is forced to re-authenticate every access_token_duration (default 1h), instead of being transparently refreshed until refresh_token_duration (default 7d). Operators currently work around this by inflating access_token_duration, which weakens security (long-lived, non-revocable JWTs).

Root cause: frontend/src/connect/refreshToken.ts calls navigator.locks.request(...) unconditionally. navigator.locks (Web Locks API) only exists in secure contexts (HTTPS or localhost); on a plain-http origin it is undefined, so the call throws and refreshTokens() rejects, causing authInterceptor to treat refresh as failed and log the user out. The refresh-token cookie transport itself is fine (backend sets Secure=false on http).

Steps to reproduce

1. Run/access the Bytebase web UI via http:// (e.g. http://10.0.0.1:8080, not https and not localhost).
2. Log in.
3. Wait longer than access_token_duration without logging out (or set access_token_duration shorter to reproduce faster).
4. Perform any action in the UI.

Expected behavior

The access token expires after access_token_duration and is transparently refreshed using the refresh token, so the user stays signed in. A full re-authentication should only be required when the refresh token expires (refresh_token_duration, default 7d) or when inactive_session_timeout triggers — not on every access_token_duration.

Provide the database you are using

No response

Additional context

No response