feat: added async getSession/getUser method

[alaister]

What kind of change does this PR introduce?

This is a proof of concept for a new async getSession() method. This allows users to get a valid session (not expired) as opposed to the synchronous session() method, which may return an expired session.

Additional context

I know we're planning to discuss this further, but since I already had most of the code, I thought I'd throw something together quickly. It will hopefully make our discussion clearer if we have something to look at!

Once gotrue-js has a method like this (or similar) it will allow supabase-js to work something like:

async function getAccessToken() {
    const {session} = await auth.getSession()

    return session?.access_token ?? null
}

const postgrestClient = new PostgrestClient({ getAccessToken, ... })

Then whenever postgrestClient is about to send a query, it can call the getAccessToken() method, which will return an up-to-date token.

Note: While this isn't a breaking change in gotrue-js (purely additive), it will be a breaking change once we start doing the above in supabase-js, as some users may rely on the first request possible sending an expired token. We may consider ignoring this use case though, as it is a strange one!

Resolves #143 and #23
Supersedes #265 and #147

[inian]

have some threshold here? we already have a constate for this i think

[alaister]

Is it needed here? If this handler works for only refreshing the token if it's already somehow expired, and the regular refresh timer handles refreshing tokens early, users rarely have to wait for the refresh request before their normal request.

Not opposed to it, just wondering what the benefits are vs the drawbacks?

[soedirgo]

@alaister instead of getAccessToken in postgrest-js and storage-js, wdyt about using this approach instead?

// SupabaseClient constructor
this.rest = new PostgrestClient(url, {
  ...,
  fetch: async (input, init) => {
    const headers = init?.headers ?? {}
    const accessToken = await getAccessToken()
    if (accessToken) {
      headers['Authorization'] = `Bearer ${accessToken}`
    }
    return this.fetch(input, { ...init, headers })
  },
})

[alaister]

@soedirgo That works too!

Did you see this: supabase/storage-js#67? It essentially makes all of the headers async. What are your thoughts on the benefits/drawbacks of all three approaches?

[soedirgo]

Ah yup, that works as well.

I think the only real drawback of .getAccessToken()/.getHeaders() is that it's kind of specific to supabase-js, and it feels weird for people using postgrest-js/storage-js directly that headers are set using a callback.

Meanwhile the .fetch() override kinda stretches the functionality of custom fetch - it's not really how it's meant to be used.

[alaister]

I agree that a custom fetch is the most flexible, but you're right does feel a bit dirty.

Personally, I could go either way between the custom fetch and async getHeaders. One thing nice about getHeaders is we can expose it to users who want to get an access token some other way, and it feels like a first-party solution. That being said, we can just document how to use the custom fetch like that without adding any additional API surface area.

@inian would love your thoughts here too.

[github-actions]

🎉 This PR is included in version 1.23.0-next.1 🎉

The release is available on:

• GitHub release
• npm package (@next dist-tag)

Your semantic-release bot 📦🚀

[github-actions]

🎉 This PR is included in version 2.0.0-rc.1 🎉

The release is available on:

• GitHub release
• npm package (@rc dist-tag)

Your semantic-release bot 📦🚀