Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: allow gotrue to work with multiple custom domains #999

Merged
merged 14 commits into from
May 12, 2023

Conversation

kangmingtay
Copy link
Member

@kangmingtay kangmingtay commented Mar 20, 2023

What kind of change does this PR introduce?

  • Improves on feat: Support for OAuth callback proxy. #725, albeit with a slightly different approach
  • When a request is made to gotrue, gotrue will retrieve the hostname and use it in the email links / oauth callback.
  • This helps to make gotrue usable with multiple custom domains, and also allows the email links to contain the custom domain.

@kangmingtay kangmingtay self-assigned this Mar 20, 2023
@kangmingtay kangmingtay requested a review from a team as a code owner March 20, 2023 08:20
Copy link
Contributor

@hf hf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general looks good, but how does it work with SAML? What are the SAML URLs advertized when you get the metadata?

@kangmingtay
Copy link
Member Author

@hf good catch, we can always display the current API_EXTERNAL_URL as the default, but if they use a custom domain in the metadata url, it should also go through the same check to verify that the domain being used is in the allow list

internal/mailer/mailer_test.go Outdated Show resolved Hide resolved
@J0
Copy link
Contributor

J0 commented Apr 3, 2023

Thanks for your patience - generally LGTM as well. There's quite a bit of overlap with the PKCE PR - do. you want to get this in first? Will save quite a bit of conflict resolution

If we haven't yet we should also test this out with a proxy server

@kangmingtay
Copy link
Member Author

@J0 sounds good - lemme finish up the deployment plan first to make sure that it won't break any existing projects

If we haven't yet we should also test this out with a proxy server

I managed to test this out by editing the /etc/hosts file locally to map localhost:9999 to a custom domain. But i'll also put it on a project in staging to see if it works with the current custom domain set up.

internal/mailer/mailer.go Outdated Show resolved Hide resolved
Copy link
Contributor

@hf hf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks OK, I'd just reconsider the hostname allow list as I don't think it does much.

internal/conf/configuration.go Outdated Show resolved Hide resolved
internal/mailer/template.go Outdated Show resolved Hide resolved
internal/mailer/template.go Outdated Show resolved Hide resolved
internal/api/mail_test.go Outdated Show resolved Hide resolved
Copy link
Contributor

@hf hf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good!

@kangmingtay kangmingtay merged commit 91a82ed into master May 12, 2023
@kangmingtay kangmingtay deleted the km/fix-custom-domain branch May 12, 2023 17:04
@github-actions
Copy link
Contributor

🎉 This PR is included in version 2.67.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

hf added a commit that referenced this pull request May 23, 2023
With #999 custom domains were introduced, however for OAuth, the
redirect URLs should in fact be the ones specified in the config and not
ones interpreted from the `X-Forwarded-Host` header.
uxodb pushed a commit to uxodb/auth that referenced this pull request Nov 13, 2024
## What kind of change does this PR introduce?
* Improves on supabase#725, albeit with a slightly different approach
* Gotrue will accept an allow list of domains via a comma-separate
string (`DOMAIN_ALLOW_LIST`) , which includes the `API_EXTERNAL_URL` by
default. On each request, gotrue will check that the domain being used
is also included in the allow list.
* When gotrue starts up, it will take the `DOMAIN_ALLOW_LIST` and
convert it into a map where the key is the hostname and the value is the
url
* When a request is made to gotrue, gotrue will check the
`DomainAllowListMap` to check if there is a matching hostname before
allowing the request through. If there isn't a matching hostname used,
gotrue will default to use the `API_EXTERNAL_URL` instead.
* This helps to make gotrue usable with multiple custom domains, and
also allows the email links to contain the custom domain.
* Since the `EXTERNAL_XXX_REDIRECT_URI` is derived during runtime, we
can remove that config once this PR is merged in as long as the
`REDIRECT_URI` is also included in the `DOMAIN_ALLOW_LIST`

---------

Co-authored-by: Joel Lee <lee.yi.jie.joel@gmail.com>
uxodb pushed a commit to uxodb/auth that referenced this pull request Nov 13, 2024
With supabase#999 custom domains were introduced, however for OAuth, the
redirect URLs should in fact be the ones specified in the config and not
ones interpreted from the `X-Forwarded-Host` header.
LashaJini pushed a commit to LashaJini/auth that referenced this pull request Nov 13, 2024
## What kind of change does this PR introduce?
* Improves on supabase#725, albeit with a slightly different approach
* Gotrue will accept an allow list of domains via a comma-separate
string (`DOMAIN_ALLOW_LIST`) , which includes the `API_EXTERNAL_URL` by
default. On each request, gotrue will check that the domain being used
is also included in the allow list.
* When gotrue starts up, it will take the `DOMAIN_ALLOW_LIST` and
convert it into a map where the key is the hostname and the value is the
url
* When a request is made to gotrue, gotrue will check the
`DomainAllowListMap` to check if there is a matching hostname before
allowing the request through. If there isn't a matching hostname used,
gotrue will default to use the `API_EXTERNAL_URL` instead.
* This helps to make gotrue usable with multiple custom domains, and
also allows the email links to contain the custom domain.
* Since the `EXTERNAL_XXX_REDIRECT_URI` is derived during runtime, we
can remove that config once this PR is merged in as long as the
`REDIRECT_URI` is also included in the `DOMAIN_ALLOW_LIST`

---------

Co-authored-by: Joel Lee <lee.yi.jie.joel@gmail.com>
LashaJini pushed a commit to LashaJini/auth that referenced this pull request Nov 13, 2024
With supabase#999 custom domains were introduced, however for OAuth, the
redirect URLs should in fact be the ones specified in the config and not
ones interpreted from the `X-Forwarded-Host` header.
LashaJini pushed a commit to LashaJini/auth that referenced this pull request Nov 15, 2024
## What kind of change does this PR introduce?
* Improves on supabase#725, albeit with a slightly different approach
* Gotrue will accept an allow list of domains via a comma-separate
string (`DOMAIN_ALLOW_LIST`) , which includes the `API_EXTERNAL_URL` by
default. On each request, gotrue will check that the domain being used
is also included in the allow list.
* When gotrue starts up, it will take the `DOMAIN_ALLOW_LIST` and
convert it into a map where the key is the hostname and the value is the
url
* When a request is made to gotrue, gotrue will check the
`DomainAllowListMap` to check if there is a matching hostname before
allowing the request through. If there isn't a matching hostname used,
gotrue will default to use the `API_EXTERNAL_URL` instead.
* This helps to make gotrue usable with multiple custom domains, and
also allows the email links to contain the custom domain.
* Since the `EXTERNAL_XXX_REDIRECT_URI` is derived during runtime, we
can remove that config once this PR is merged in as long as the
`REDIRECT_URI` is also included in the `DOMAIN_ALLOW_LIST`

---------

Co-authored-by: Joel Lee <lee.yi.jie.joel@gmail.com>
LashaJini pushed a commit to LashaJini/auth that referenced this pull request Nov 15, 2024
With supabase#999 custom domains were introduced, however for OAuth, the
redirect URLs should in fact be the ones specified in the config and not
ones interpreted from the `X-Forwarded-Host` header.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants