config push sends [auth.sms] enable_confirmations un-negated as sms_autoconfirm, so hosted projects get the opposite of local
Maintainer thường phản hồi trong vòng 1 ngày
@7ttp đang làm issue này rồi.
Từ ngày 5/10/2026.
Đánh giá
Issue này chưa được đánh giá.
Mô tả
Affected area
Auth
Supabase CLI version
v2.98.0. The same code is on develop as of 2026-10-05.
Operating system
Ubuntu (GitHub Actions ubuntu-latest) for config push; macOS for supabase start.
Installation method
npm (via supabase/setup-cli@v3)
Command
supabase config push, compared with supabase start on the same config.toml.
Actual output
With this in supabase/config.toml:
[auth.email]
enable_confirmations = true
[auth.sms]
enable_confirmations = true
after supabase config push, the hosted project's GET /auth/v1/settings returns:
{ "mailer_autoconfirm": false, "phone_autoconfirm": true }
and the dashboard (Authentication > Sign In / Providers > Phone) shows "Enable phone confirmations" switched off.
So the email key means "require confirmation" and the identical SMS key means "skip confirmation". Locally, supabase start with the same file does require phone confirmation, so one config behaves in opposite ways on a local stack and on a hosted project.
Expected behavior
[auth.sms] enable_confirmations = true should set sms_autoconfirm = false on the hosted project, the way [auth.email] enable_confirmations = true sets mailer_autoconfirm = false, and the way supabase start already treats the SMS key.
Steps to reproduce
- Set
[auth.sms] enable_confirmations = trueinsupabase/config.toml. - Run
supabase link --project-ref <ref>andsupabase config push. - Run
curl https://<ref>.supabase.co/auth/v1/settings -H "apikey: <publishable key>". It returns"phone_autoconfirm": true, and the dashboard's Phone provider shows "Enable phone confirmations" off. - Run
supabase startwith the same file. The local auth container getsGOTRUE_SMS_AUTOCONFIRM=false.
Additional context
Cause. In pkg/config/auth.go (v2.98.0; apps/cli-go/pkg/config/auth.go on develop) the email mapping negates in both directions and the SMS mapping does not:
// email
body.MailerAutoconfirm = nullable.NewNullableWithValue(!e.EnableConfirmations) // L700
e.EnableConfirmations = !ValOrDefault(remoteConfig.MailerAutoconfirm, false) // L825
// sms
body.SmsAutoconfirm = nullable.NewNullableWithValue(s.EnableConfirmations) // L1121
s.EnableConfirmations = ValOrDefault(remoteConfig.SmsAutoconfirm, false) // L1170
internal/start/start.go negates both:
fmt.Sprintf("GOTRUE_MAILER_AUTOCONFIRM=%v", !utils.Config.Auth.Email.EnableConfirmations) // L1309
fmt.Sprintf("GOTRUE_SMS_AUTOCONFIRM=%v", !utils.Config.Auth.Sms.EnableConfirmations) // L1325
Because the read-back (L1170) is un-negated as well, the pushed value round-trips and config push has no diff to show for the key, so nothing flags it.
Why it matters. With sms_autoconfirm on, a phone number is marked confirmed without an OTP, both on signup and on PUT /user {phone}. A project that sets enable_confirmations = true believes it requires phone verification and does not.
Suggested fix. Negate L1121 and L1170 to match the email mapping. That flips the hosted value for any project that has worked around this by setting false, so it needs a release note.
History. Reported before as #4413, which was closed as not planned without a fix.
- Ngôn ngữ chính
- TypeScript
- Star
- 2.4k
- Fork
- 531
- Merge trung bình
- 1 ngày 4 giờ
- Pull request đã merge (30 ngày)
- 351
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của supabase/cli
-
db schema declarative sync: no way to fail (non-zero exit) when the generated migration is destructiveCó thể làm lại được Pull request cho issue này đã bị đóng mà không được merge. Đang mở✨ Feature supabase/cli
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
Maintainer thường phản hồi trong vòng 1 ngày
-
stack: the HTTP gateway closes idle keep-alive connections after 5 s, so a client whose event loop is blocked gets ECONNRESET (`fetch failed`) on its next requestCó thể đã có người làm @7ttp đã nhận 6 ngày trước. Đang mở🐛 Bug supabase/cli
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
supabase/cli#6975 · 1 người được giao ·
Maintainer thường phản hồi trong vòng 1 ngày
-
📘 Docs supabase/cli
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
supabase/cli#6974 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Migration error caret is missing or misplaced when the statement contains multibyte charactersĐang mở🐛 Bug supabase/cli
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Maintainer thường phản hồi trong vòng 1 ngày
-
stack: a database helper stays behind as a `Created` container when readiness times out mid-createCó thể đã có người làm @just-some-random-pal đã nhận 1 ngày trước. Đang mở🐛 Bug open-for-contribution supabase/cli
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 18/100
Maintainer thường phản hồi trong vòng 1 ngày
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 85/100
MystenLabs/MemWal#1163 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Mondriaan
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
knaw-huc/textannoviz#709 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
billion-context-pi
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
ranxianglei/billion-context#2521 · 3 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Add: YRF Music NepalĐang mởstreams:add
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100