fix(frontend): refresh the session token without Web Locks on plain HTTP by RaphaelFakhri · Pull Request #21616 · bytebase/bytebase · GitHub
Skip to content

fix(frontend): refresh the session token without Web Locks on plain HTTP - #21616

Open
RaphaelFakhri wants to merge 1 commit into
bytebase:mainfrom
RaphaelFakhri:fix/refresh-token-insecure-context
Open

RaphaelFakhri wants to merge 1 commit into
bytebase:mainfrom
RaphaelFakhri:fix/refresh-token-insecure-context

Conversation

@RaphaelFakhri

Copy link
Copy Markdown

Fixes #21575.

Cause

tryAcquireAndRefresh in frontend/src/api/refreshToken.ts calls navigator.locks.request unconditionally. The Web Locks API exists only in secure contexts (HTTPS or localhost). On a plain http:// origin navigator.locks is undefined, so refreshTokens() rejects with TypeError: Cannot read properties of undefined (reading 'request'). authInterceptor treats that as a failed refresh and signs the user out every access_token_duration, even though the refresh-token cookie is valid (the backend sets Secure only on HTTPS).

Fix

  • When navigator.locks is unavailable, refresh directly and broadcast completion, the same as the locked path.
  • Same-tab deduplication through localPromise still applies, so concurrent requests in one tab share one refresh.
  • The locked path for secure contexts is unchanged; the refresh-and-broadcast step moves into a shared helper.

Without Web Locks there is no cross-tab coordination, so two tabs that refresh at the same moment can still race on the single-use refresh token. That case is rare compared with the current behavior, where every refresh on HTTP fails.

Validation

  • New frontend/src/api/refreshToken.test.ts (3 tests). Before the fix, the 2 tests without Web Locks fail with the TypeError above; after the fix, all 3 pass.
  • pnpm --dir frontend fix: no changes. Gate stages run individually: biome ci, guard scripts, tsc --build --force, vite build --mode release and vitest run (577 files, 6546 tests) pass.
  • Not checked in a browser against an HTTP deployment.

Breaking changes

None.

navigator.locks exists only in secure contexts, so on an http:// origin
the token refresh threw and every expired access token logged the user
out. Refresh directly when Web Locks is unavailable.

Fixes bytebase#21575
@RaphaelFakhri
RaphaelFakhri requested a review from a team as a code owner October 18, 2026 11:01
@chatgpt-codex-connector

chatgpt-codex-connector Bot commented Oct 18, 2026 •

Copy link
Copy Markdown

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Web token auto-refresh broken on http (non-secure-context) deployments — forces re-login every access_token_duration instead of refresh_token_duration

1 participant