[supabase newbie] Don't understand why refresh token doesn't extend my login after 1-hour access token expiration

[J0ELh]

I'm picking up the code setup by a recently offboarded member of our team. He set up all the supabase code and I'm here to maintain it.

Problem: I have noticed when using google or regular sign in, after 1 hour, I get logged out and see the following message in my client console:

Error in API route handler: Error: No valid user
    at getServerAccessToken (webpack-internal:///(rsc)/./src/lib/supabase/actions.ts:95:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async POST (webpack-internal:///(rsc)/./src/app/api/route.ts:13:23)
    at async C:\Users\[hidden path]\client\node_modules\next\dist\compiled\next-server\app-route.runtime.dev.js:6:62609
Error in API route handler: Error: No valid user
    at getServerAccessToken (webpack-internal:///(rsc)/./src/lib/supabase/actions.ts:95:15)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async POST (webpack-internal:///(rsc)/./src/app/api/route.ts:13:23)
    at async C:\Users\[hidden path]\client\node_modules\next\dist\compiled\next-server\app-route.runtime.dev.js:6:62609

I need to manually go to the login page and click on the google login option to continue using the application.

Given my limited understanding, the expected behavior using supabase is that after my 1 hour access token expires, my refresh token should fetch a new bundle of access and refresh tokens from supabase and this should automatically keep my session up and running. Is this true? If so, then what could be the reason for my sessions ending after my access token expires?

Please let me know if there is any code I need to share (like the middleware.ts, or any of the supabase/actions.ts /client.ts /middleware.ts or /server.ts

[GaryAustin1]

Your assumption is correct. Supabase-js clients will refresh the access token (jwt) before it expires with a timer. They also store the tokens in local storage and when the app starts up will refresh the token behind the scenes (can take awhile so you have to await getSession). That is all browser stuff.

If you have server code also involved then you have to use something like auth-helpers/SSR to use a cookie to keep all the different clients refreshed or take care of it yourself.

[J0ELh]

I see. In this case, it seems like there's indeed an issue with the token not being refreshed.

From the area where the code was thrown (actions.ts), I previously had this:

export const getServerAccessToken = async () => {
  const supabase = createClient();

  const {
    data: { user },
  } = await supabase.auth.getUser();

  if (!user) {
    throw new Error("No valid user");
  }

  const {
    data: { session },
  } = await supabase.auth.getSession();

  if (!session) {
    throw new Error("No valid session");
  }

  return session.access_token;
};

Would this be a better solution? Trying to refresh the session manually if the token is expired?

export const getServerAccessToken = async () => {
  const supabase = createClient();

  // Try to get the user directly
  let { data: { user }, error: userError } = await supabase.auth.getUser();

  // If no user found, possibly due to an expired token, attempt to refresh
  if (!user) {
    if (userError && userError.status === 401) { // Check if it's an auth error indicating expired tokens
      const { error: refreshError } = await supabase.auth.refreshSession();
      if (refreshError) {
        // If refreshing the session also fails, redirect or handle error
        throw new Error("Session refresh failed, user needs to log in again");
      }
      // Try fetching the user again after refreshing the token
      user = (await supabase.auth.getUser()).data.user;
      if (!user) {
        throw new Error("No valid user after token refresh");
      }
    } else {
      // If there's no user and it's not an auth error, throw a generic error
      throw new Error("No valid user");
    }
  }

  // Now get the session to return the access token
  const { data: { session }, error: sessionError } = await supabase.auth.getSession();
  if (!session) {
    throw new Error("No valid session");
  }

  return session.access_token;
};

[GaryAustin1]

I'm not the one to comment on best ways to do your own refreshing instead of using something like SSR. I don't use server side supabase myself.

[j4crev]

Are you using Supabase on the server-side? If so, I'd highly recommend the ssr package.

[GaryAustin1]

I would check all your clients are SSR clients and not using Supabase-js (unless service role).

Otherwise some how a cookie is stale in part of your code.

SSR should take care of refreshing.

[J0ELh]

From testing I can see that the time set for expiry is never updated. This means my token is never refreshed. I have setup the code similar to the docs with no logical differences. You seem to be indicating that I should not manually refresh the token and instead middleware should be refreshing the session using cookies.

1. How can I see the response from the supabase server? There must be some sort of error if my cookie truly stale.

2. In the following boilerplate snippet that is responsible for refreshing, why are we setting the cookies before refreshing the session? Shouldn't they be set after awaiting the new session?

import { createServerClient, type CookieOptions } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";


export async function updateSession(request: NextRequest) {
  let response = NextResponse.next({
    request: {
      headers: request.headers,
    },
  });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_ANON_KEY!,
    {
      cookies: {
        get(name: string) {
          return request.cookies.get(name)?.value
        },
        set(name: string, value: string, options: CookieOptions) {
          request.cookies.set({
            name,
            value,
            ...options,
          })
          response = NextResponse.next({
            request: {
              headers: request.headers,
            },
          })
          response.cookies.set({
            name,
            value,
            ...options,
          })
        },
        remove(name: string, options: CookieOptions) {
          request.cookies.set({
            name,
            value: '',
            ...options,
          })
          response = NextResponse.next({
            request: {
              headers: request.headers,
            },
          })
          response.cookies.set({
            name,
            value: '',
            ...options,
          })
        },
      },
    }
  )

  await supabase.auth.getUser()

  return response
}

[GaryAustin1]

I'll bow out as I don't use SSR, but I do know that when setup and used properly it handles all refreshing for you. You are not expected to deal with it.

[J0ELh]

Thank you up to this point! Maybe someone else can chime in who knows more about SSR

[j4crev]

@J0ELh regarding your 2nd question, about the cookies, there is a possible known issue for this. There's a PR which supposedly fixes it here, if you don't mind reading that. You can probably skip the first two sections.

I'm sure people have Next setup and working with ssr - otherwise we'd know about it. However, apparently there have been issues.

[J0ELh]

This was the solution to my problem