Soviut commented 2 years ago

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:

1.

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

Sign in to GitHub
Get redirected back to /
Note the #access_token=xxx hash that remains
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/supabase-js@2.0.0-rc.4
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 commented 2 years ago

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 commented 2 years ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

Will likely get fixed with #574.

whollacsek commented 1 year ago

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

yakhinvadim commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

timeisgolden commented 1 year ago

@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 commented 1 year ago

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 commented 1 year ago

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

silverbackdan commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

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

j4w8n commented 1 year ago

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 commented 1 year ago

installing @supabase/gotrue-js helped

j4w8n commented 1 year ago

@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 commented 1 year ago

I am facing same issue with latest version 2.33.1

Monu18765 commented 1 year ago

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

Chaoyingz commented 1 year ago

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 commented 1 year ago

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

akrv commented 1 year ago

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"