feat: adds support for wildcards in redirect URIs

[milanvanschaik]

What kind of change does this PR introduce?

Feature: adds support for wildcards in redirect URIs.

What is the current behavior?

Currently, it's only possible to pass exact redirect URIs in the allowed redirect URIs list. This becomes a problem when, for example, working with automatic feature branch deployments on subdomains, because currently you would have to add the new generated subdomain to the allowed redirect URIs list by hand. As discussed here: supabase/supabase#4808

What is the new behavior?

This PR adds support for wildcards in redirect URIs trough globbing. Now it's possible to add *.mydomain.com as a redirect URI and have x.mydomain.com and y.mydomain.com accepted.

Since this is quite a critical (security wise) part of GoTrue I would love to hear thoughts on this.
Also I haven't touched Go for bigger projects in 5+ years, so with that in mind, very open for feedback and suggestions. There might be a better performing implementation?

Please let me know if you have any additional questions.

Additional context

Some things that still might need some discussion: supabase/supabase#4808 (comment)

[J0]

Looks good to me. We can discuss further during catchup if needed

[awalias]

looks good but can we add a couple more test cases:

https://*.x.com where https://a.b.x.com fails
and
https://*.*.x.com where https://a.b.x.com passes

and maybe a few more if we can get creative to try and catch all the edge cases (wild card in the path? https://x.com/*/foo etc. )

[bnjmnt4n]

I think it would be great to link to the documentation for valid glob syntax (https://pkg.go.dev/github.com/gobwas/glob#Compile).

The docs also recommend doing compilation of globs a single time for performance. I'm guessing this might not be an issue for most users, but eventually repeated compilation of globs on every redirect request might lead to performance penalties.

[kangmingtay]

The docs also recommend doing compilation of globs a single time for performance. I'm guessing this might not be an issue for most users, but eventually repeated compilation of globs on every redirect request might lead to performance penalties.

Thanks for catching this! I've moved the glob compilation for the uri allowed list to when gotrue initially starts up and loads the config so we only compile the globs once.

[github-actions]

🎉 This PR is included in version 2.6.19 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

[mrpbennett]

Hi All,

I am having slight issues when using Google Auth redirect with my project. I have set the Google auth for internal folk only, this is how I have set up the URLs in supabase.

But when trigging the below function I just get redirected to https://s3-directory-npi.vercel.app/home#access_token=xxx with a 404

const signInWithGoogle = async () => {
    const {user, session, error} = await supabase.auth.signIn(
      {
        provider: 'google',
      },
      {
        redirectTo: 'https://s3-directory-npi.vercel.app/home',
      },
    )

    if (error) {
      popupValidation('error', error.message)
    }
  }

Any suggestions to resolve the issue would be great.

[pie6k]

Just lost like 2 hours trying to solve dynamic auth redirect not knowing about that. I tried custom query params, queryParams option of auth SDK, even saving dynamic value in localStorage as a last resort.

Please try to add notes about such a feature in the panel in the future. Simple "You can use glob patterns" would do the job. Copy in the panel clearly indicates I need strict, exact match urls

[[rage level / trying to write politely]] ratio = 8000

[Jutanium]

Seconding. Please update the copy on the dashboard!

[thorwebdev]

Until we have docs for this you can refer to supabase/supabase#4808 (comment) for an overview.