access_token hash remains in URL after sign-in with OAuth provider

[Soviut]

Bug report

Describe the bug

I'm using Vue 3 with Vue Router 4 (latest). I'm using OAuth for sign-in, specifically github. The flow works fine and redirects back, but the #access_token=XXX hash remains visible until I navigate to another page.

This happens regardless of what I set redirectTo. It redirects to that page, but the hash remains on it, regardless of which page I use.

(my workarounds are in the additional details)

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

await supabase.auth.signInWithOAuth({
  provider: 'github',
})

2. Sign in to GitHub
3. Get redirected back to /
4. Note the #access_token=xxx hash that remains
5. Click a link to navigate to another page, hash goes away

Expected behavior

Hash will appear briefly, then once supabase is done authenticating the hash should be removed by doing a history.replace() so you can't press the back button to get to the route with the hash in it.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: Ubutu 20 (running in WSL2 on Windows 10)
• Browser (if applies) Chrome
• Version of supabase-js: @supabase/[email protected]
• Version of Node.js: v16.14.2

Additional context

I've tried two workarounds,

My first workaround was to redirectTo a callback page which immediately redirects to the intended destination without the hash. This works but does a bunch of redirect the user can see.

Next, I tried to use supabase.onAuthStateChange() to check the hash and immediately replace it. This seemed to work at first, but it seems there's a race condition to when the event triggers versus when the hash updates, so checking for the #access_token= presence wasn't reliable.

supabase.auth.onAuthStateChange(() => {
  if (route.hash.startsWith('#access_token=')) {
    router.replace({ hash: '' })
  }
})

Finally, my current workaround is to use a Vue watch to watch the current route's hash for changes.

watch(
  () => route.hash,
  (hash) => {
    if (hash.startsWith('#access_token')) {
      router.replace({ hash: '' })
    }
  },
  { immediate: true }
)

[CodysCodingCloud]

I know that this is regarding v2, however a similar issue occurs in v1. oddly when using OAuth on local host, the hash does get evaluated immediately and the site would refresh. However when I attempted to deploy to heroku using a custom domain and updating the Site URL in the supabase dashboard, the hash remains the URL. something I found interesting was that if I were to try OAuth in local host with the deployed Site URL in the dashboard, the hash does get updated. the reverse also allows the hash to be evaluated

[kirbby]

Same for MagicLink Login in Vue 3 and Vue Router 4 using hash routes. I had the feeling sometimes the access_token gets cleared and everything works and sometimes it stays and then shows my 404 Page not found, because of the hash routing. (only tested locally, not with a built project)

[j4w8n]

I think this more of a framework and/or browser issue. I came across the same thing with SvelteKit.

I do a client-side navigation after sign-in, which resolves this (user's login from /login, so a redirect is warranted anyway). Even if staying on the same url after login, client-side nav doesn't cause any flicker of content. However, the url with hash ends up in the browser history if you don't have a way of clearing it with your framework or natively.

[j4w8n]

I read this too quickly and misunderstood. I was thinking you were saying it was simply leaving the #.

Unfortunately, I haven't been able to reproduce your issue.

[hf]

Will likely get fixed with #574.

[whollacsek]

@hf is this fixed since then? I see that you've reverted https://github.com/supabase/gotrue-js/pull/574

[yakhinvadim]

I'm seeing this issue in gotrue-js 2.24.0, access_token remains in the URL after the redirect. I'm using Google provider.

@hf should the issue be reopened?

[KazakovKirill]

I have same issue with Nuxt 3 and supabase OAuth:

[Vue Router warn]: The selector "#access_token=..." is invalid. If you are using an id selector, make sure to escape it. You can find more information about escaping characters in selectors at https://mathiasbynens.be/notes/css-escapes or use CSS.escape (https://developer.mozilla.org/en-US/docs/Web/API/CSS/escape).

Has anyone found a solution how to fix this?

"@nuxtjs/supabase": "^0.3.5", "nuxt": "^3.4.3"

[staniboy]

I have same issue with Nuxt 3 and supabase OAuth:

[Vue Router warn]: The selector "#access_token=..." is invalid. If you are using an id selector, make sure to escape it. You can find more information about escaping characters in selectors at https://mathiasbynens.be/notes/css-escapes or use CSS.escape (https://developer.mozilla.org/en-US/docs/Web/API/CSS/escape).

Has anyone found a solution how to fix this?

"@nuxtjs/supabase": "^0.3.5", "nuxt": "^3.4.3"

Same problem here with Supabase OAuth (Google provider) and Nuxt 3

[r-this]

Same problem here with Supabase OAuth (Github provider) and Nuxt 3

@augustpemberton Also having the same problem - not sure if it's related, but I'm using SSR and it seems like I also don't get a user session on the client-side.

I don't get a user session either. No cookie set. I tried fresh minimal starter (npx nuxi init <project-name>), same issue. After I removed Github it seemed like I was still having the issue with MagicLink. I stopped at that point, didn't verify. It's easy to peel the hash off but the app is still broken so it wasn't an effective workaround.

[augustpemberton]

Also having the same problem - not sure if it's related, but I'm using SSR and it seems like I also don't get a user session on the client-side.

[martinkogut]

We're encountering a similar issue within our environment, and it appears to be manifesting differently depending on the browser used.

In Chrome, we are observing that users are not assigned a session, resulting in a null user object. However, the behavior is slightly different in Safari, where users are able to log in successfully but subsequently encounter an internal Vue error.

Here are the relevant packages and their versions:

"@nuxtjs/supabase": "0.3.8" "nuxt": "^3.6.5"

[meyiapir]

I have the same problem with all my Supabase projects on Nuxt latest versions. I've been trying to solve it for the second day, nothing helps.

[meyiapir]

I fixed the authorization by just taking the old package-lock.json - I'm shocked why it works!

[timeisgolden]

@meyiapir Did you fix the issue? If so, can you please let me know the nuxt & supabase version? I have same issue and am struggling on it.

[Mradosi]

I had the same issue and I fixed it by updating Nuxt to "^3.6.5", Supabase to ""^0.3.8"" and adding overrides to package,json:

    "@supabase/supabase-js": {
      "@supabase/gotrue-js": "2.43.1"
    }
  }

[meyiapir]

@timeisgolden "@nuxtjs/supabase": "^0.3.8", "nuxt": "3.6.5",

[silverbackdan]

Interesting @meyiapir - I've done a fresh install with those versions and I have the issue everyone else has listed using the opt (magic link) login.

[silverbackdan]

I also get this console error on every load Multiple GoTrueClient instances detected in the same browser context. It is not an error, but this should be avoided as it may produce undefined behavior when used concurrently under the same storage key.

And on the page with a user is redirected to [Vue Router warn]: The selector "#access_token=[JWT_TOKEN_HERE]&expires_in=3600&refresh_token=[MY_TOKEN]&token_type=bearer&type=magiclink" is invalid. If you are using an id selector, make sure to escape it. You can find more information about escaping characters in selectors at https://mathiasbynens.be/notes/css-escapes or use CSS.escape (https://developer.mozilla.org/en-US/docs/Web/API/CSS/escape).

[silverbackdan]

The overrides sorted it for me. For pnpm package.json:

{
  ...
  "pnpm": {
    "overrides": {
      "@supabase/gotrue-js": "2.43.1"
    }
  }
}

[j4w8n]

For anyone that's commented since ~7/20: at this point, you should be able to upgrade supabase-js to v2.31.0 and be good - without overrides.

[ponochovny]

installing @supabase/gotrue-js helped

[j4w8n]

@ponochovny the @supabase/gotrue-js package is taken care when you install @supabase/supabase-js; so make sure installing directly doesn't somehow cause you issues in the future.

[Monu18765]

I am facing same issue with latest version 2.33.1

[Monu18765]

I don't know it seem to get fix automatically after 5 minutes.

[Chaoyingz]

The same situation occurs when the signup email is sent using supabase.auth.resend. The callback api does not get the code, but there is an access_token parameter in the url.

[Monu18765]

I think there is some hickup on the backend. Try after some time see if it get fixed on its own.

[akrv]

having the same issue. doesnt work on a hosted version. works on localhost only on chrome. safari doesn't work at all.

supabase lib versions with node 18.17 deployed on netlify.

"@supabase/supabase-js": "2.33.2", "@supabase/functions-js": "^2.1.5", "@supabase/gotrue-js": "^2.51.0", "@supabase/node-fetch": "^2.6.14", "@supabase/postgrest-js": "^1.8.4", "@supabase/realtime-js": "^2.7.4", "@supabase/storage-js": "^2.5.4"

[jackiepapers]

No user session. Access token has #.

[guillaumeduhan]

Same issue here.