Refresh token bug

[mykhailodanilenko]

If coming back to the site after a long period, the user does not get a notification saying they need to reauthenticate and instead keeps using the same stale token everywhere

[mblomdahl]

@claude It seems like there is a bug in the HTTP request interceptor, causing the user to be prompted to login, even though we might still have a valid refresh token and do not need to re-authenticate. Please analyze, think deeply and report on your findings.

[claude]

Claude finished @mblomdahl's task —— View job

---

Analysis Complete

Todo List

• Locate and read HTTP request interceptor code
• Locate and read authentication/token management code
• Analyze token refresh logic
• Identify bugs in token handling
• Report detailed findings

---

Findings

I've analyzed the authentication flow and identified multiple bugs in the HTTP request interceptor that explain both issues mentioned:

Bug #1: Stale Tokens Used Without Notification (Original Issue)

Location: OwnTube.tv/api/axiosInstance.ts:143-148

When both access and refresh tokens are expired, the code sets sessionExpired: true and aborts the request, BUT it still returns the config object and allows the request to potentially proceed:

if (!accessTokenValid && !refreshTokenValid && session) {
  await useAuthSessionStore.getState().updateSession(backend, { sessionExpired: true });
  controller.abort("Session expired, aborting request");
  postHogInstance.capture(CustomPostHogEvents.SessionExpired);
  return config; // ⚠️ BUG: Still returns config, request may proceed
}

Problem: The interceptor updates the session state to mark it as expired and calls controller.abort(), but:

1. Returns the original config object, which means axios might still attempt the request with the stale token
2. The controller.abort() call uses a shared AbortController instance created at module level (line 22), which means aborting affects ALL requests globally, not just this one
3. There's no guarantee the request will actually be blocked

Expected behavior: The interceptor should throw an error or return a rejected promise to prevent the request from proceeding with stale credentials.

Bug #2: Premature Login Prompts (Comment Issue)

Location: OwnTube.tv/api/axiosInstance.ts:124-141

The refresh logic has a critical flaw in its condition:

if (
  (now > proactiveRefreshThreshold && refreshToken && shouldAttachAccessToken) ||
  (!accessTokenValid && refreshTokenValid)  // ⚠️ BUG: Missing session check
) {
  try {
    if (!refreshToken) throw new Error("Missing refresh token");
    const refreshed = await refreshAccessToken(backend, refreshToken);
    // ...
  } catch (err) {
    console.error("Refresh token attempt failed", err);
    // ⚠️ BUG: Silently swallows error, continues without valid token
  }
}

Problems:

1. Line 126: The condition !accessTokenValid && refreshTokenValid doesn't check if there's an active session at all
2. This means if session is undefined or null, but somehow the variables are in a state where accessTokenValid is false and refreshTokenValid is true, it will attempt a refresh with potentially undefined values
3. Lines 137-140: When token refresh fails, the error is caught and logged but the request continues without a valid token
4. The subsequent check on line 143 only triggers if BOTH tokens are invalid, so if refresh fails, the request proceeds with an invalid token

Bug #3: Response Interceptor Race Condition

Location: OwnTube.tv/api/axiosInstance.ts:154-176

The response interceptor handles 401 errors independently:

axiosInstance.interceptors.response.use(
  (resp) => resp,
  async (error) => {
    const status = error?.response?.status;
    if (status === 401) {
      // Sets sessionExpired: true
      await useAuthSessionStore.getState().updateSession(backend, { sessionExpired: true });
    }
    return Promise.reject(error);
  }
);

Problem: This creates a race condition where:

• The request interceptor might be attempting a token refresh
• A 401 response comes back from a different request
• The response interceptor sets sessionExpired: true
• The refresh attempt completes successfully but the session is already marked as expired
• User sees "signed out" modal even though tokens were just refreshed

Bug #4: Shared AbortController

Location: OwnTube.tv/api/axiosInstance.ts:22

const controller = new AbortController();

Problem: A single AbortController instance is shared across all requests. When one request's session expires and calls controller.abort(), it cancels ALL pending requests, not just the one with the expired token.

---

Root Causes Summary

1. Stale tokens continue to be used: Request interceptor doesn't properly block requests when tokens expire
2. Failed refresh is silent: When token refresh fails, the error is swallowed and requests proceed anyway
3. Premature login prompts: Race conditions between request/response interceptors and insufficient session state checks
4. Global abort side effects: Shared AbortController affects all requests when one expires

---

Recommended Fixes

1. Request interceptor should throw: Replace return config with throw new Error("Session expired") at line 147
2. Create per-request AbortController: Each request should have its own signal, not a shared one
3. Don't swallow refresh errors: If token refresh fails, mark session as expired and throw error
4. Add session existence checks: Verify session exists before attempting refresh operations
5. Add refresh state locking per request: Current lock only prevents concurrent refreshes, but doesn't handle failed refreshes properly

---

Summary: The bugs stem from improper error handling in the request interceptor. When tokens expire, requests continue with stale credentials instead of being blocked. When refresh fails, errors are silently swallowed. This causes both the original issue (stale tokens used without notification) and the reported issue (premature login prompts due to race conditions).

Would you like me to implement fixes for these issues?

---

Branch: claude/issue-451-20251022-0649
Job Run: Link

[mblomdahl]

@claude Some errors are corrected now with yesterday's pull request #481, but I need additional time to test and verify that the refresh logic works (or does not, we'll see). One low-hanging fruit and annoyance in the UI is that the session info is shown as "Användare {EMAIL} vid {BACKEND_HOSTNAME}, med tvåfaktor av, session startad 2025-10-25 13:29, uppdaterad 2025-10-25 13:29, aktiv, refresh token utfärdad 2025-10-25 13:29". Or upon copying client info into JSON format via the Client Settings pop-up:

{"buildInfo":{"BUILD_TIMESTAMP":"2025-10-24T17:48:12Z"},"OS":"Mac OS version 10.15.7","dimensions":"2560 x 1440","device":"Apple Macintosh","orientation":"landskap","deviceType":"DESKTOP","browser":"Safari 26.0.1","playerImplementation":"video.js","authInfo":{"backend":"BACKEND_HASTNAME","email":"EMAIL","twoFactorEnabled":false,"sessionCreatedAt":"2025-10-25T11:29:22.975Z","sessionUpdatedAt":"2025-10-25T11:29:22.975Z","sessionExpired":false,"accessTokenIssuedAt":"2025-10-25T11:29:22.975Z","refreshTokenIssuedAt":"2025-10-25T11:29:22.975Z","userInfoUpdatedAt":"2025-10-25T11:29:23.187Z"},"backend":{"hostname":"BACKEND_HOSTNAME","version":"7.3.0"}}

On all devices I've tested, when authenticated it seems that session started at timestamp is always shown as the latest token refresh time, not the initial refresh token issue time from first login. Can you please investigate what is the actual issue here and then reply with a information-complete prompt that I can send to the Copilot AI agent on GitHub to have any corrections applied?

[claude]

Claude finished @mblomdahl's task —— View job

---

Investigation Complete

Summary

I've identified the root cause of the session timestamp issue and prepared a complete prompt for GitHub Copilot to implement the fix.

---

Root Cause

The bug is in OwnTube.tv/utils/auth.ts:15 in the parseAuthSessionData() function:

sessionCreatedAt: new Date().toISOString(),

The Problem:

This function is called in two different contexts:

1. Initial login (OwnTube.tv/screens/SignIn/index.tsx:101 and OwnTube.tv/screens/Otp/index.tsx)
2. Token refresh (OwnTube.tv/api/axiosInstance.ts:132)

When refreshing tokens, the code calls:

const parsed = parseAuthSessionData(refreshed, backend);
await updateSession(backend, parsed);

The parseAuthSessionData() function always sets sessionCreatedAt to the current time, which overwrites the original login timestamp during token refresh.

What should happen:

• sessionCreatedAt should be set only on initial login and never change during token refresh
• accessTokenIssuedAt and refreshTokenIssuedAt should update during token refresh (current behavior is correct)
• sessionUpdatedAt should always update (current behavior is correct)

---

Prompt for GitHub Copilot

Here's the complete, information-rich prompt you can send to GitHub Copilot:

---

Bug Report: Session timestamp incorrectly updates during token refresh

Problem: When users authenticate and then tokens are refreshed (either proactively or reactively), the session start timestamp (sessionCreatedAt) is incorrectly updated to show the latest token refresh time instead of preserving the original login time.

Root Cause: The parseAuthSessionData() function in OwnTube.tv/utils/auth.ts is used for both initial login AND token refresh, but it always sets sessionCreatedAt to the current time using new Date().toISOString().

Current Behavior:

• User logs in at 2025-10-25 11:00:00
• Tokens refresh at 2025-10-25 13:00:00
• Session info shows: sessionCreatedAt: "2025-10-25T13:00:00.000Z" (WRONG - should be 11:00:00)
• User sees "session startad 2025-10-25 13:00" in UI instead of original login time

Expected Behavior:

• sessionCreatedAt should remain "2025-10-25T11:00:00.000Z" (original login time)
• sessionUpdatedAt should update to "2025-10-25T13:00:00.000Z" (current behavior is correct)
• accessTokenIssuedAt and refreshTokenIssuedAt should update to "2025-10-25T13:00:00.000Z" (current behavior is correct)

Solution Required:

Modify OwnTube.tv/utils/auth.ts to accept an optional parameter indicating whether this is an initial login or a token refresh:

1. Add a new parameter isRefresh?: boolean to parseAuthSessionData() function
2. When isRefresh is true, do not set sessionCreatedAt (omit it from returned object so it's not overwritten by updateSession())
3. When isRefresh is false or undefined (initial login), set sessionCreatedAt as currently done
4. Update the call site in OwnTube.tv/api/axiosInstance.ts:132 to pass isRefresh: true:

   const parsed = parseAuthSessionData(refreshed, backend, true);

5. Existing call sites in login screens don't need changes (they'll use default isRefresh = false or undefined)

Files to Modify:

1. OwnTube.tv/utils/auth.ts - Update function signature and logic:

   export const parseAuthSessionData = (
     loginResponse: UserLogin & { expires_in: number; refresh_token_expires_in: number },
     backend: string,
     isRefresh?: boolean,  // ADD THIS PARAMETER
   ): Partial<AuthSession> => {
     const { getConfigByBackend } = useInstanceConfigStore.getState();
     const instanceConfig = getConfigByBackend(backend);
   
     const res = {
       backend,
       basePath: "/api/v1",
       twoFactorEnabled: false,
       // Only set sessionCreatedAt on initial login, not during refresh
       ...(!isRefresh && { sessionCreatedAt: new Date().toISOString() }),
       sessionUpdatedAt: new Date().toISOString(),
       sessionExpired: false,
       tokenType: loginResponse.token_type,
       accessToken: loginResponse.access_token,
       accessTokenIssuedAt: new Date().toISOString(),
       accessTokenExpiresIn:
         instanceConfig?.customizations?.loginAccessTokenExpirationOverride ?? loginResponse.expires_in,
       refreshToken: loginResponse.refresh_token,
       refreshTokenIssuedAt: new Date().toISOString(),
       refreshTokenExpiresIn:
         instanceConfig?.customizations?.loginRefreshTokenExpirationOverride ?? loginResponse.refresh_token_expires_in,
     };
   
     return res;
   };

2. OwnTube.tv/api/axiosInstance.ts - Update call site at line 132:

   const parsed = parseAuthSessionData(refreshed, backend, true);  // Pass true for isRefresh

Testing:

1. Sign in to the application
2. Note the "session startad" timestamp in Settings or Client Info JSON
3. Wait for token refresh to occur (or trigger it by waiting past TOKEN_REFRESH_LIFETIME_PERCENTAGE of token lifetime)
4. Check the session timestamp again - it should remain unchanged from initial login
5. Verify sessionUpdatedAt, accessTokenIssuedAt, and refreshTokenIssuedAt DO update to reflect the refresh

TypeScript Compatibility: The change is backwards compatible - existing call sites will use the default value and continue to work correctly.

---

End of Copilot Prompt

---

You can copy the entire section between the horizontal rules (starting with "Bug Report:" and ending with "TypeScript Compatibility:") and send it to GitHub Copilot to have the fix implemented.

---

Branch: claude/issue-451-20251025-1134