Skip to content

Conversation

@EpochBoy
Copy link

@EpochBoy EpochBoy commented Nov 18, 2025

Correction

Updated to Documentation-Only

After reviewer feedback, this is now a documentation improvement rather than code change.

What Changed

Updated [auth.email].enable_signup and [auth.sms].enable_signup comments in config templates to clarify:

  • These control the entire provider (GOTRUE_EXTERNAL_*_ENABLED), not just signup
  • false = provider disabled (no login/invites/OTP/signup)
  • true = provider enabled (signup requires [auth].enable_signup=true)
  • Added configuration examples for invite-only, open signups, and disabled providers

Issue: supabase/supabase#40582
Companion PR: supabase/supabase#40575

Original PR

Fixes supabase/supabase#40582

Problem

When using invite-only authentication ([auth].enable_signup=false and [auth.email].enable_signup=false), the CLI incorrectly disables the entire email/phone authentication providers instead of just preventing self-signups.

This causes:

  • 422 email_provider_disabled errors when attempting to use OTP/magic links
  • Users unable to accept invites in invite-only flows
  • Confusing behavior where config semantics don't match expectations

Root Cause

Lines 487 and 502 in internal/start/start.go map:

  • utils.Config.Auth.Email.EnableSignupGOTRUE_EXTERNAL_EMAIL_ENABLED
  • utils.Config.Auth.Sms.EnableSignupGOTRUE_EXTERNAL_PHONE_ENABLED

This conflates two distinct concerns:

  1. Provider existence (should the provider be available at all?)
  2. Signup control (can users self-signup via this provider?)

Solution

Set GOTRUE_EXTERNAL_EMAIL_ENABLED=true and GOTRUE_EXTERNAL_PHONE_ENABLED=true when auth is enabled, since:

  • The outer if utils.Config.Auth.Enabled check (line 460) already gates provider initialization
  • Email/SMS config structs have no Enabled field, only EnableSignup
  • Signup is controlled separately via GOTRUE_DISABLE_SIGNUP (line 478)

This fixes the inconsistency:

  • Email/phone providers (Supabase's built-in authentication) should be enabled when auth is configured
  • EnableSignup should only control whether users can self-register, not whether the provider exists
  • OAuth providers (Google/GitHub/etc.) use a separate provider.Enabled field for this reason
  • The Docker Compose fix (fix(docker): separate auth provider enabled from signup settings supabase#40575) introduces separate ENABLE_EMAIL_PROVIDER and ENABLE_PHONE_PROVIDER variables following the same pattern

Testing

Before:

[auth]
enable_signup = false

[auth.email]
enable_signup = false

After:
Same config now works - invites accepted ✅, OTP works ✅, self-signup blocked ✅

Fixes supabase/supabase#
Companion PR: supabase/supabase#40575 (Docker Compose fix)

Fixes email/phone authentication providers being incorrectly disabled
when `enable_signup=false` is set in config.toml, which broke
invite-only authentication setups.

The CLI was incorrectly mapping `[auth.email].enable_signup` and
`[auth.sms].enable_signup` to `GOTRUE_EXTERNAL_EMAIL_ENABLED` and
`GOTRUE_EXTERNAL_PHONE_ENABLED`, conflating provider enablement with
signup control. This caused the providers to be completely disabled,
returning "email_provider_disabled" errors even for invite-only flows.

Now email and phone providers are always enabled when `[auth].enabled=true`,
aligning with the Docker Compose fix in supabase/supabase#XXXX.
Signup control is handled separately via `GOTRUE_DISABLE_SIGNUP` which
is already correctly mapped from `[auth].enable_signup`.

This matches the OAuth provider pattern where providers are always
enabled when configured, with separate control for signup permissions.
Copilot AI review requested due to automatic review settings November 18, 2025 14:23
@EpochBoy EpochBoy requested a review from a team as a code owner November 18, 2025 14:23
@EpochBoy EpochBoy closed this Nov 18, 2025
Copilot finished reviewing on behalf of EpochBoy November 18, 2025 14:25
Copy link

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR fixes a critical bug where email and phone authentication providers were incorrectly disabled during local development when enable_signup=false was set in the config, breaking invite-only authentication flows. The fix decouples provider enablement from signup control to match the OAuth provider pattern.

Key changes:

  • Hardcode GOTRUE_EXTERNAL_EMAIL_ENABLED=true and GOTRUE_EXTERNAL_PHONE_ENABLED=true in local development environment
  • Rely on existing GOTRUE_DISABLE_SIGNUP for signup control, which is properly mapped from [auth].enable_signup

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@coveralls
Copy link

coveralls commented Nov 18, 2025

Pull Request Test Coverage Report for Build 19531912999

Details

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • 5 unchanged lines in 1 file lost coverage.
  • Overall coverage decreased (-0.03%) to 55.082%

Files with Coverage Reduction New Missed Lines %
internal/gen/keys/keys.go 5 12.9%
Totals Coverage Status
Change from base Build 19526850899: -0.03%
Covered Lines: 6530
Relevant Lines: 11855

💛 - Coveralls

@sweatybridge
Copy link
Contributor

sweatybridge commented Nov 19, 2025

Unfortunately your change makes [auth.email] enable_signup = false completely useless as the email provider will always be enabled.

When using invite-only authentication ([auth].enable_signup=false and [auth.email].enable_signup=false), the CLI incorrectly disables the entire email/phone authentication providers instead of just preventing self-signups.

To achieve what you described, you want to use the following config instead.

[auth]
enable_signup = false

[auth.email]
enable_signup = true

@EpochBoy
Copy link
Author

You are correct! My apologies for the confusion.

However, I think the current comment could be clearer since this setting does more than just control signups. What if we changed:

[auth.email]
# Allow/disallow new user signups via email to your project.
enable_signup = true

To something like:

[auth.email]
# Controls whether the email authentication provider is enabled (GOTRUE_EXTERNAL_EMAIL_ENABLED).
# 
# false = Email provider completely disabled (no login, invites, OTP, or signup)
# true  = Email provider enabled (login, invites, OTP work; signup requires [auth].enable_signup=true)
# 
# Common configurations:
#   Invite-only:    [auth].enable_signup=false, [auth.email].enable_signup=true
#   Open signups:   [auth].enable_signup=true,  [auth.email].enable_signup=true
#   No email auth:  [auth.email].enable_signup=false (regardless of [auth].enable_signup)
enable_signup = true

This would help prevent others from encountering the same confusion I did. Happy to update both my PRs to just improve the documentation if that would be helpful!

EpochBoy and others added 2 commits November 19, 2025 12:49
…t signup

Updated config template comments for [auth.email] and [auth.sms]
enable_signup to explain these control the entire provider, not just
signup. Added invite-only configuration examples.
@EpochBoy
Copy link
Author

@sweatybridge Updated the issue and both PR's, hope this is more helpful ☺️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Bug: enable_signup=false disables entire email/phone provider instead of just signups

3 participants