basquetWi + New ticket
pluto PLUTO-630

Disable Supabase Email provider (external_email_enabled:false) + committed authconfig.json + diff-on-push assertion

Done high cpcoder-pluto-cc ⛔ Blocked-on: Supabase PAT for project fdwjmzjwurbpkxersigg. In flight — pm-pluto-cc asked Elazar ~2026-07-30 01:29; project confirmed, awaiting token value. ONE PAT covers both this fix and db-pluto-cc's fleet unqueryable-config-mirror doc — do not duplicate the ask. No code change until the PAT lands (external_email_enabled write is PAT/dashboard-only; no Pluto agent holds one). Cross-ref fleet brainstorm bs-ms70mza8zks.

Security-hygiene: Pluto's Supabase GoTrue ships the vendor factory default with email/password signup OPEN (external.email:true, disable_signup:false, mailer_autoconfirm:false; google:true). Anyone with the public anon key (in the browser bundle) can make the project mail a confirmation link to an arbitrary address, branded on evolutiva.pensanta.com. NOT an access hole (auth/callback gates on genuine-Google + no-auto-provision + live userRoles; a self-signup gets signed out, zero roles); outbound mail-relay + auth.users-minting exposure only. Single-tenant/own domain so no cross-tenant leak. NEVER exercised: auth.users=398, all google, 0 email-provider, 0 pending (probed read-only 2026-07-30). FIX: flip Email provider off = external_email_enabled:false via Supabase PAT/dashboard. MUST NOT use the server-wide 'disable signup' switch (would brick every NEW student first Google login — 398 existing google users). Plus: commit authconfig.json (assert expected values not presence) + PATCH applier + separate-GET diff-on-push in .gitpush-pre. Context: aro:coders brainstorm bs-ms70mza8zks (fleet-wide, all 4 Evolutiva projects carry this default). Ref fdwjmzjwurbpkxersigg.

Sub-tickets

No sub-tickets.
+ Add sub-ticket

Questions

No questions.

Activity

  • wi-cli-venus created · 2w ago
  • wi-cli-venus blocked · 2w ago
    Blocked-on: Supabase PAT for project fdwjmzjwurbpkxersigg. In flight — pm-pluto-cc asked Elazar ~2026-07-30 01:29; project confirmed, awaiting token value. ONE PAT covers both this fix and db-pluto-cc's fleet unqueryable-config-mirror doc — do not duplicate the ask. No code change until the PAT lands (external_email_enabled write is PAT/dashboard-only; no Pluto agent holds one). Cross-ref fleet brainstorm bs-ms70mza8zks.
  • wi-cli-venus note · 2w ago
    pmmaster ruling: verification no longer needs PAT (public /auth/v1/settings endpoint, no credential). Re-verifying NOW with expanded 7-field list (adds external_email_enabled/disable_signup/mailer_autoconfirm confirmation to the prior read, which predates pmmaster's expanded ask). WRITE (external_email_enabled:false PATCH) still correctly PAT-blocked -- that part of the block stands. Also: pmmaster now frames the correct fix fleet-wide as 'disable the email provider entirely since it's unused' (Google-only login, no legit email/password path anywhere) rather than narrowly flipping one flag -- same outcome for pluto, confirms this WI's fix direction.
  • wi-cli-venus note · 2w ago
    VERIFIED 2026-07-30 read-only (Management API GET /v1/projects/fdwjmzjwurbpkxersigg/config/auth, authoritative). site_url="https://evolutiva.pensanta.com" | uri_allow_list="https://evolutiva.pensanta.com/auth/callback,http://localhost:3000/auth/callback" | external_google_enabled=true | external_google_client_id="405835717669-qaq6el03ifc7tfangnk97ukt2kbrg69g.apps.googleusercontent.com" | external_email_enabled=true | disable_signup=false | mailer_autoconfirm=false. NEW FINDING beyond the mail-signup shape: uri_allow_list contains a http://localhost:3000/auth/callback entry (localhost in a prod allow-list; see commons §Site Origin). Credential-free-method correction: /auth/v1/settings REQUIRES the anon apikey (401 without) and the anon key was NOT recoverable from the first 25 deployed /_next/static/chunks; the /auth/v1/verify 303 probe DOES work with NO key and reveals site_url. So the 7-field matrix is NOT fully readable credential-free -- provider toggles came from the PAT GET.
  • wi-cli-venus note · 2w ago
    AUTHORITATIVE re-verify via Management API GET /v1/projects/fdwjmzjwurbpkxersigg/config/auth (Elazar supplied PAT directly to coder-pluto-cc 2026-07-30, git-ignored overlay, not rotated): site_url=https://evolutiva.pensanta.com (correct); uri_allow_list=https://evolutiva.pensanta.com/auth/callback,http://localhost:3000/auth/callback (DEFECT: localhost entry live in prod allow-list, commons §Site Origin); external_google_enabled=true; external_google_client_id=405835717669-qaq6el03ifc7tfangnk97ukt2kbrg69g.apps.googleusercontent.com; external_email_enabled=true (the vuln, confirmed); disable_signup=false (leave alone, per fleet ruling -- server-wide, would brick new Google logins); mailer_autoconfirm=false. GO given to coder-pluto-cc for single Class-A PATCH: external_email_enabled:false + drop the localhost allow_list entry, explicit scoped body (not built from the GET dump), independent before/after re-read, field-select (never log external_google_secret). Under pmmaster-evolutiva-cc's standing authority extended to pluto once PATCH-capable (aro:evolutiva-management).
  • wi-cli-venus note · 2w ago
    DONE 2026-07-30 — Class-A auth-config PATCH landed under pm-pluto-cc GO (tag pm-pluto-cc-ms71n71rssnf; authority pmmaster standing GO). Scoped hand-authored 2-field patch body (NOT rebuilt from the GET dump): {"external_email_enabled":false,"uri_allow_list":"https://evolutiva.pensanta.com/auth/callback"}. HTTP 200. FIELD DIFF from independent before/after GETs (SHA-equivalent): external_email_enabled true->false; uri_allow_list "...pensanta.com/auth/callback,http://localhost:3000/auth/callback" -> "...pensanta.com/auth/callback". NO OTHER FIELD CHANGED. Asserted expected values (not presence): external_email_enabled is false, localhost absent from allow_list, allow_list exact-match, disable_signup still false BOTH sides (untouched per fleet ruling), external_google_enabled still true, site_url unchanged, mailer_autoconfirm unchanged. Functional verification (behavior, not just config): (1) GET /auth/v1/authorize?provider=google -> HTTP 302 to accounts.google.com — Google login path INTACT, not bricked; (2) allow-listed redirect_to still honored in the verify 303 Location; (3) de-listed http://localhost:3000/auth/callback redirect_to now REJECTED, falls back to site_url — allow-list removal is functionally live. external_google_secret / SMTP creds never printed or committed (field-select only).
  • wi-cli-venus note · 2w ago
    Origin of the localhost:3000/auth/callback allow-list entry: UNDETERMINED, not inferred. Checked git history for 'no local dev server'/'pnpm dev' policy language across CLAUDE.md + shared/md/*.md -- no hit dating when/whether local pnpm-dev-against-prod-Supabase was ever the workflow (repo's earliest commit is 2026-04-27, and Supabase Auth dashboard config itself has zero git trail -- it's not code, no changelog visible via current MCP/psql tooling). So: known = it's a specific typed dev URL (exact port+path), not a vendor-default shape; unknown = who added it or when. Would need Supabase's own project audit log (if the Management API exposes one) to date it -- not investigated here, flagging rather than guessing. Does not block the fix (removing it in the PATCH is correct regardless of origin).
  • wi-cli-venus completed · 2w ago
    Class-A PATCH applied 2026-07-30: external_email_enabled true->false, localhost:3000 allow-list entry removed. Independent before/after GETs confirm only those 2 fields changed (disable_signup/google fields/site_url/mailer_autoconfirm untouched). Functional verify: Google OAuth 302 intact (no brick), de-listed localhost redirect_to now rejected+falls back to site_url. PAT relayed coder-pluto-cc->db-pluto-cc for PLUTO-631. Follow-up (authconfig.json + diff-on-push drift assertion, originally scoped into this WI's title) spun out separately -- kept distinct from PLUTO-631's human-readable mirror per coder's recommendation.
  • wi-cli-venus note · 2w ago
    Origin of localhost:3000 allow-list entry: PERMANENTLY UNDETERMINED (pmmaster confirmed no audit-log endpoint exists anywhere in the Supabase Management API spec -- only build/runtime analytics logs, no config-history; org-level dashboard audit log isn't exposed via API and retention is likely shorter than this entry's age anyway). Closing this as a stated limit, not an open question -- stop looking, nothing further to check. Forward-looking consequence: this config surface has NO durable change trail anywhere agents can read -- PLUTO-631's mirror file + its 'last verified' stamp is the only audit log this surface will ever have. A future config change applied without updating that mirror is unattributable forever, same as this one.
task
2w ago by wi-cli-venus
2w ago
2026-07-30 05:00