Follow-up to #571 / #496 — the fix from #571 (released in v2.0.5) only triggers when useSsrCookies: false is explicitly set, leaving users on the default config still hitting the original symptom.
Version
@nuxtjs/supabase: v2.0.6
nuxt: v4.4.2
Steps to reproduce
-
Create a Nuxt 4 app with ssr: false.
-
Install @nuxtjs/supabase@2.0.6 with the default config — do not set useSsrCookies:
export default defineNuxtConfig({
ssr: false,
modules: ['@nuxtjs/supabase'],
supabase: {
url: process.env.SUPABASE_URL,
key: process.env.SUPABASE_KEY,
redirectOptions: {
login: '/login',
callback: '/confirm',
exclude: ['/login', '/confirm'],
},
},
})
-
Add a /login page that calls supabase.auth.signInWithPassword and a protected route.
-
Sign in successfully — you land on the protected page.
-
Hard-refresh the browser.
What is Expected?
Either of:
- The user remains signed in on refresh in SPA mode without needing extra config, or
- The docs clearly prescribe the required SPA configuration. Currently
useSsrCookies is mentioned only on the introduction page, with no reference to ssr: false, no "SPA / CSR-only" section, and no example pairing the two settings.
What is actually happening?
The user is redirected to /login on every refresh. The fix from #571 (released in v2.0.5) only runs when useSsrCookies: false is explicitly set:
if (!useSsrCookies) {
const { data } = await client.auth.getSession()
if (data.session) currentSession.value = data.session
}
With the default useSsrCookies: true and no SSR running, nothing populates currentSession synchronously, so the global auth-redirect middleware sees session.value === null and navigates to login before onAuthStateChange fires.
This same suggestion was made as a side note in #496 ("maybe it could use ssr flag from nuxt config as a default, instead of being true, while ssr is false") but doesn't appear to have been picked up.
Suggestions:
- Auto-default
useSsrCookies to false when ssr === false in the Nuxt config, or
- Add an "SPA / CSR-only" section to the docs that prescribes
ssr: false + useSsrCookies: false and explains why both are needed.
Follow-up to #571 / #496 — the fix from #571 (released in v2.0.5) only triggers when
useSsrCookies: falseis explicitly set, leaving users on the default config still hitting the original symptom.Version
@nuxtjs/supabase: v2.0.6
nuxt: v4.4.2
Steps to reproduce
Create a Nuxt 4 app with
ssr: false.Install
@nuxtjs/supabase@2.0.6with the default config — do not setuseSsrCookies:Add a
/loginpage that callssupabase.auth.signInWithPasswordand a protected route.Sign in successfully — you land on the protected page.
Hard-refresh the browser.
What is Expected?
Either of:
useSsrCookiesis mentioned only on the introduction page, with no reference tossr: false, no "SPA / CSR-only" section, and no example pairing the two settings.What is actually happening?
The user is redirected to
/loginon every refresh. The fix from #571 (released in v2.0.5) only runs whenuseSsrCookies: falseis explicitly set:With the default
useSsrCookies: trueand no SSR running, nothing populatescurrentSessionsynchronously, so the globalauth-redirectmiddleware seessession.value === nulland navigates tologinbeforeonAuthStateChangefires.This same suggestion was made as a side note in #496 ("maybe it could use ssr flag from nuxt config as a default, instead of being true, while ssr is false") but doesn't appear to have been picked up.
Suggestions:
useSsrCookiestofalsewhenssr === falsein the Nuxt config, orssr: false+useSsrCookies: falseand explains why both are needed.