Better URLs for hooks

[RickMeasham]

At the moment if someone attempts to re-use the magic login URL they are redirected to the front end with a 404 in the location hash:

http://localhost:3000#error_code=404&error_description=User+not+found

And if someone is doing a password reset:

http://localhost:3000#access_token=x&refresh_token=y&expires_in=z&token_type=bearer&type=recovery

These are fairly arbitrary and ultimately the only way to handle it is pattern matching. The example realtime chat app does a browser level redirect based on the precise hash content. That's really inefficient!

Is there any way that we can get less arbitrary URLs or be able to specify a URL for various events?

Less arbitrary (also: the ability to choose between a hash and a query string please?):

#supabase_event=expired_magic
#supabase_event=password_reset&access_token=x&refresh_token=y&expires_in=z&token_type=bearer&type=recovery

Specified would be up to the app owner:

http://localhost:3000/login?error_code=expired_magic
http://localhost:3000/login/reset/<access_token>

[awalias]

thanks for ideas @RickMeasham !

Sounds like mostly backend changes required here, feel free to open specific issues in https://github.com/supabase/gotrue

I will have a think on how the interface can be standardised without too many breaking changes. One idea is to ensure a type= is added to all responses including errors, or as you mention a supabase_event although this one might require us to double up on responses that already have a type.

I'm open to adding a CUSTOM_REDIRECT_DELIMITER to gotrue, although I'm a little hesitant that it might result in compatibility issues in the future - e.g. some apps or frameworks only work with the # or ? delimiter and don't work out the box with whichever the default backend is. And having to support both (in supabase-js/supabase-dart/... for example might become a burden for maintainers)

open to further input on these, thanks for kick-starting the discussion!

[RickMeasham]

Thanks for your reply and openness. I've had a look at the gotrue fork to understand the implications.

I am probable misunderstanding how something fits together, but I think we would be OK having a CUSTOM_REDIRECT_DELIMITER as it would only be used for the webhooks. The SDKs wouldn't need to know about it as they don't do the hook handling (as far as I am aware). They would still be sending requests to the API in the exact same format as they currently do.

The reason for suggesting the supabase_event parameter was so a frontend could tell it was getting a request from supabase. We could handle that by just adding a static source=supabase parameter in all the hooks, and as you say, always include a type.

The other option might be to have a config for the webhook base URL. That way all the hooks could be sent to https://localhost:3000/supabase_hook?type=invite&foo=bar and developers can segregate the hooks from any other requests.

I might have a play with gotrue and see if I can get a PR together (uh oh, yak shaving!), but I think the dashboard isn't open so if we have an option to change the CUSTOM_REDIRECT_DELIMITER one of your team would need to expose it there.

Would you be open to a PR? (Even if it's just to create discussion)