GoTrueClient is unable to retrieve session when setting accessToken in global.headers for SSR applications

[miguel-flowalytics]

Bug report

Describe the bug

After removing setAuth it's recommend to set an accessToken via global.headers. Here's an example: https://github.com/supabase/gotrue-js/pull/340#issuecomment-1218065610

Unfortunately, this breaks auth functionality. I'm unable to retrieve a session using getSession() or user with getUser() (which relies on getSession).

But I'm able to make requests to select data.

To Reproduce

This is for a Remix project. So I took the advice to create a client per request, like so:

const supabase = createClient(supabaseUrl, supabaseKey, {
    auth: {
      autoRefreshToken: false,
      detectSessionInUrl: false,
      persistSession: false,
    },
    global: {
      headers: {
        Authorization: `Bearer ${accessToken}`,
      },
    },
  });

Because this is a SSR application, there's no need to persistSession. But this is the very option that blocks the client from getting a session. GoTrueClient._initialize does not set this.inMemorySession

Another thing, I'm using on Remix's createCookieSessionStorage API. Which handles setting cookie session for the user. I extract the access token from this API and then set it in createClient. I'm handling refresh token logic in the Remix route level.

1. createClient per request as advised here
2. Call getSession
3. Get no session or user

Expected behavior

I should be able to retrieve session and user information. This is necessary to handle refreshToken logic at the server-side route level.

Screenshots

attached under Describe the bug

System information

• OS: macOS
• Browser (if applies) chrome
• Version of supabase-js: 2.0.0-rc.10
• Version of Node.js: v16.16.0

Additional context

• If this is an intended behavior of removing setAuth, how to handle refresh token logic in a SSR application?