fix: prefer Site URL over origin-only Referer for email redirects#2629
Open
rohanpatel2002 wants to merge 1 commit into
Open
fix: prefer Site URL over origin-only Referer for email redirects#2629rohanpatel2002 wants to merge 1 commit into
rohanpatel2002 wants to merge 1 commit into
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What kind of change does this PR introduce?
Bug fix
What is the current behavior?
When sending a signup confirmation email, Auth chooses the post-confirm redirect with
GetReferrer()in this order:redirect_to(query/header)RefererheaderFor apps hosted on a path-based origin (for example GitHub Pages at
https://user.github.io/repo/), a browserPOSTto*.supabase.cois cross-origin. With a typicalReferrer-Policysuch asstrict-origin-when-cross-origin, the browser often sends an origin-only Referer (https://user.github.io/), with the/repo/path removed.Because that origin still matches the Site URL hostname, Auth treats it as valid and prefers it over a Site URL that includes the project path. The confirmation link then contains:
instead of the intended:
In addition,
POST /signupdid not readredirect_to/email_redirect_tofrom the JSON body (SignupParamshad no such fields). Clients that only sent the redirect in the body therefore fell through to the Referer / Site URL logic above.Relevant issue: #2634
What is the new behavior?
GetReferrer: if the fallback candidate is an origin-only Referer (empty path or/) and Site URL has a non-root path, prefer Site URL. An explicitredirect_tostill takes precedence. Referers that already include a path are unchanged.SignupParamsacceptsredirect_toandemail_redirect_tofrom the JSON body and, when allow-listed, uses that value for the confirmation email.Unit coverage was added for the origin-only Referer vs path-based Site URL case.
Additional context
This is aimed at path-based deployments (GitHub Pages project sites and similar). Password recovery already behaved correctly when
redirect_towas supplied as a query parameter; this change mainly fixes signup confirmation when Auth would otherwise trust a stripped Referer, and when the redirect is only present in the signup JSON body.Happy to adjust naming, tests, or scope if maintainers prefer a narrower change. Thank you for reviewing.