Moving getSession() into client from useSupabaseUser() #244
Conversation
Properly updating useSupabaseUser()
✅ Deploy Preview for n3-supabase canceled.
|
Aietes
force-pushed
the
patch-supabase_client
branch
from
3b9bd23
to
4f36ae0
Compare
| if (event === 'SIGNED_IN' || event === 'TOKEN_REFRESHED') { | ||
| if (session?.user) { |
There was a problem hiding this comment.
Why not keeping this line for all events ? We ensure we are always up to date and don't need to add a custom line for USER_UPDATED AND SIGNED_OUT ?
| useCookie(`${cookieName}-access-token`, cookieOptions).value = session?.access_token | ||
| useCookie(`${cookieName}-refresh-token`, cookieOptions).value = session?.refresh_token | ||
| if (session.provider_token) useCookie(`${cookieName}-provider-token`, cookieOptions).value = session.provider_token |
There was a problem hiding this comment.
Why remove it ? There are still module users that are using it I think.
| const user = useState<User | null>('supabase_user', () => null) | ||
|
|
||
| // Asyncronous refresh session and ensure user is still logged in | ||
| supabase?.auth.getSession().then(({ data: { session } }) => { |
There was a problem hiding this comment.
"useSupabaseUser() relies on useState(), which is updated on auth events from the supabase client" => Why not keeping this async call to also relies on the useSupabaseUser call ?
| } | ||
| }) | ||
|
|
||
| // attempt to retrieve an existing session from local storage | ||
| await supabaseClient.auth.getSession() |
There was a problem hiding this comment.
This call fix the client rendered page issue since it ensures the session/user is set on client side refresh. It means we need to update the confirm.vue page in the playground and the documentation (also mention it in the release):
const user = useSupabaseUser()
if (user.value) {
await navigateTo('/user')
}
should be enough, we don't need to watch it no more.
Resolves #236
Properly updating useSupabaseUser()
Types of changes
Description
Using a different approach to check the session validity. The getSession() method has been moved into the supabase.client.ts, it now ensures an existing session in local storage will be reused and refreshed when a client is created. It also ensures useSupabaseUser() is updated according to the auth events occurring in the supabase-js client. This should solve the issues with non-SSR pages.
The downside of this approach is that an actual check for a session is only occurring in the setup function of the supabase.client, which occurs only once, or on refresh or switching to a different SSR mode route. The rest of the module relies on useSupabaseUser to accurately reflect a valid session, and useSupabaseUser() relies on useState(), which is updated on auth events from the supabase client.
This is probably fine in most cases, but a condition can occur in which useSupabaseUser() returns a user from useState(), when there is no valid session and user in place, as an explicit check doesn't occur. This can lead to a situation in which queries to RLS-protected tables return no data, and it's not apparent that the auth state is responsible. However, calling useSupabaseClient().auth.getSession() anywhere in the app should fix that state.
Checklist: