Mailer drops path component of API_EXTERNAL_URL when building confirmation URLs

Open
#2,518 3 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
go

Research direction

Start at the mailer URL-building code that parses API_EXTERNAL_URL and appends the GOTRUE_MAILER_URLPATHS_* suffix; search for those configuration names and reproduce with the documented OTP request. Check confirmation, recovery, invite, and email-change links through the Mailpit flow. Done means a configured path such as /auth/v1 is preserved and the generated confirmation URL reaches the routed endpoint.

Written by the indexing model from the issue text.

Description

Summary

When API_EXTERNAL_URL contains a path component (e.g. http://127.0.0.1:54321/auth/v1), the mailer discards the path while building confirmation URLs, producing links that 404 when routed through an API gateway.

Versions

  • Supabase CLI: 2.98.1
  • Bundled auth image: public.ecr.aws/supabase/gotrue:v2.188.1

Reproduction

  1. Run a local Supabase stack with default config; the auth container's env will contain API_EXTERNAL_URL=http://127.0.0.1:54321/auth/v1 and GOTRUE_MAILER_URLPATHS_CONFIRMATION=/verify.
  2. Setting [auth] external_url = "http://127.0.0.1:54321/auth/v1" explicitly in supabase/config.toml does not change the behavior (also reproduces with the stock default).
  3. POST http://127.0.0.1:54321/auth/v1/otp with { "email": "<seeded user>", "create_user": false }.
  4. Inspect the resulting magic-link email in Mailpit (http://127.0.0.1:54324).

Expected

Link URL is http://127.0.0.1:54321/auth/v1/verify?token=...&type=magiclink&redirect_to=....

Actual

Link URL is http://127.0.0.1:54321/verify?token=...&type=magiclink&redirect_to=... — missing /auth/v1.

Clicking returns Kong's {"message":"no Route matched with those values"} 404, since Kong only has a route registered for /auth/v1/verify.

Verified end-to-end:

  • GET /verify?... → 404 (no Kong route)
  • GET /auth/v1/verify?... → 303 with a valid access_token JWT in the redirect Location

Apparent root cause

The mailer parses API_EXTERNAL_URL and uses only <scheme>://<host> when concatenating the GOTRUE_MAILER_URLPATHS_* suffix — discarding any path component. With URLPATHS_CONFIRMATION=/verify and API_EXTERNAL_URL=http://127.0.0.1:54321/auth/v1, the result is http://127.0.0.1:54321/verify instead of http://127.0.0.1:54321/auth/v1/verify.

This presumably also affects the recovery, invite, and email-change paths, all of which share the same URL-building code path.

Workaround

Override the magic_link email template via Supabase CLI config and hardcode the corrected URL using {{ .TokenHash }}, {{ .RedirectTo }}, and the literal /auth/v1/verify path.

Impact

Anyone running a recent Supabase CLI locally cannot use magic-link auth out of the box without a template override or manual URL surgery. Filed downstream as johnnyrw/book-keeper#66.

Dominant language
Go
Stars
2.6k
Forks
764
Avg merge
5d 3h
Merged PRs (30d)
39

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from supabase/auth

All issues in supabase/auth

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.