Url hash is totally removed when setting session from Url

[tartard]

Bug report

Describe the bug

When the front-end uses a hash-based router like https://github.com/ItalyPaleAle/svelte-spa-router , this line breaks the routing by removing the hash from the url :
https://github.com/supabase/gotrue-js/blob/b887af5567409a189b0e700880a032c65d0d21e8/src/GoTrueClient.ts#L358

For example, let's say that when a user receives a recover password link, we want to redirect him to the page http//frontend.com/#/password which contains a reset password form.

• The user receives the recovery link by email and clicks it : http://example.supabase.io/auth/verify?token=qCjkmx2wzPO7sFFa2eDHvQ&type=recovery&redirect_to=http://frontend.com/
• The user is redirected by supabase to http://frontend.com/#access_token=...&type=recovery ...
• The app detects the access_token and type=recovery and sets the route with http://frontend.com/#/password . In the meanwhile, gotrue.js detects the access_token, sets the session, and removes the hash from the url, so it routes the user to http://frontend.com/
• The user never sees the reset password screen.

Expected behavior

Developers should be able to chose if they want the full hash to be removed from the url or not. This could be parameterized in the Gotrue client instantiation .

Also, maybe the access_token should be placed after a '?' rather than a '#' . I have seen code changes in this way ( https://github.com/supabase/gotrue/pull/97 ) , but they don't seem to be in production yet. When they will be, this line will not be relevant anymore as it won't remove the gotrue parameters from the url.

[sduduzog]

Another possible fix for this is to remove session specific properties from the hash and set the hash with what remains.

Of course this would be more flexible with an option to opt in/out of

[tartard]

Yes your solution brings less complexity I think. I submit a PR with an implementation.

[DavraYoung]

+

I'm facing the same problem with our Github pages React Hash router

[jyk2000]

This also affects when client email provider has link protection service. For example, Mimecast and SafeLink. They protect links in the email and transform to safe links. While doing so, any hash code will be removed. Hence making the auth process broken.

Ex) http://frontend.com/#access_token=...&type=recovery ... => http://frontend.com after link protection. Users of these service enabled only see transformed safe link. Resulting auth process broken.

[kangmingtay]

Hey everyone, the tokens are placed behind a query fragment because gotrue follows an oauth2 protocol known as the implicit grant flow.

This also affects when client email provider has link protection service. @jyk2000 The email link sent to the user's email does not contain any query fragment. It's typically a link of the following format (https://project-ref.supabase.co/auth/v1/verify?type=signup&token=token). Clicking on the email link will then hit the gotrue auth service which verifies the token in the query param and redirects the user to the site. The access and refresh tokens will then be found in the redirection url as query fragments.

I've tried to reproduce the following cases with the correct redirect urls in the allow list:

1. https://project-ref.supabase.co/auth/v1/authorize?provider=google&redirect_to=http://localhost3000/#/password Redirected to: http://localhost3000/#. Note that Gotrue doesn't even include the /#/password in the query fragment during the redirect here. The redirected url initially contains the #access_token=..... fragments but not the /password path.

2. https://project-ref.supabase.co/auth/v1/authorize?provider=google&redirect_to=http://localhost3000/welcome Redirected to: http://localhost3000/welcome#.

Will be transfer this to the gotrue backlog.