evolutiva
EVO-68
Auth: allow any genuine-Google-OAuth login, drop domain allowlist as login gate
Done normal
unassigned
Elazar directive (2026-07-19, relayed via pm-mars-cc): drop the institutional-domain allowlist as a LOGIN gate for Google-OAuth users. Gate login on 'genuine Google identity' (provider=google + google sub claim), NOT on email domain. Origin: real Mars alumno logs in with a Google account on a hotmail address (jhudit.jara@hotmail.com) — works today ONLY via the legacy existing-user bypass; a NEW such user is blocked by isAllowedEmailDomainAsync. Elazar wants that block removed for genuine-Google logins. SCOPE: Class-A, all 3 apps (mars/pluto/venus share isAllowedEmailDomainAsync + systemSettings.allowedEmailDomains, EVO-59). Per-app rollout, PLAN-FIRST, audit design-ping BEFORE impl. DESIGN QUESTIONS (confirm w/ Elazar in WI before impl): (a) BLAST RADIUS: this opens login/self-onboard to ANYONE with a Google-authenticated identity, any domain. Backstop: a self-onboarded user has NO role (userRoles) until an admin grants one, so login != access (role-aware redirector shows nothing). Confirm intended. (b) What the allowlist still governs post-change: nothing for Google; no non-Google providers exist today. Keep allowlist code as fallback for future non-Google providers? (c) /solicitar-acceso + auth/callback reason=email-domain path: that signOut+redirect gate goes away for Google users — decide the new behavior. (d) Canonical-email unique-index dup protection unaffected (stays). Children: MARS/PLUTO/VENUS.
Sub-tickets — 3/3 done
PLUTO-609 Done high
cpcoder-pluto-cc
Questions
No questions.
Activity
-
Elazar confirmed 2026-07-19 + corrected the model: NO auto account creation in any app. Accounts pre-created by humans from client data; users log in with the client-provided email; unmatched email -> in-app request form -> human matches to an existing student -> human updates the email. Always human approval. THEREFORE this is NOT open self-onboard — my blast-radius worry was wrong. Corrected design: new login gate = genuine Google identity (provider=google + sub) + a matching pre-created account. Drop the domain check. A genuine-Google login with NO matching account must STILL route to the request/match form and MUST NOT create a userRow. Critical per-app verify in plan-first: confirm auth/callback has no auto-create-on-first-login path that the domain gate was implicitly backstopping; if one exists, the unmatched path must go to the request form, not insert. /solicitar-acceso stays as the unmatched-user landing. GO given. Dispatching plan-first, Class-A, audit design-ping before impl.
-
Children filed 2026-07-19: MARS-518 (P1), PLUTO-609, VENUS-281. All plan-first, no push before audit design-ping (Class-A). Each verifying: auto-create backstop, allowedEmailDomains/reason=email-domain fate, canonical-index + existing-user-bypass unaffected. Awaiting plans + design-pings.
-
PLUTO-609 finding: pluto already compliant (PLUTO-465 made login domain-check log-only; zero auto-create — callback only UPDATEs pre-existing rows; unmatched login already routes to /solicitar-acceso, zero inserts). Pluto leg = near-no-op (remove dead telemetry check + dead reason=email-domain UI branch). KEY: allowedEmailDomains is load-bearing at 5 NON-login sites (import validation, admin email-change guard, a-solucionar irregularity detection, admin form hint) — EVO-68 = DETACH from login gate only, do NOT delete the setting/helpers. Forwarded to mars+venus to confirm their other consumers before touching. Canonical-index unaffected. Pluto design-ping to audit sent.
-
TAIL ITEM (do after all 3 apps ship): commons evolutiva-commons.md §Auth still mandates hard-reject of non-allowlisted callback logins — contradicts PLUTO-465 + EVO-68. Propose §Auth rewrite to coder-mars-cc (commons maintainer): state login gate (genuine-Google + matching account) SEPARATELY from allowedEmailDomains' retained non-login uses (import validation, admin email-change guard, a-solucionar irregularity detection, admin form hint). Land doc AFTER code so it matches shipped reality. PLUTO-609 audit design PASS, implementing.
-
SCOPE RULING 2026-07-19 (mars MARS-518 surfaced): fold in the /solicitar-acceso SUBMIT gate. Callback-only strands the target user — off-domain genuine-Google user logs in but request-submit domain-gate rejects them (mars solicitar-acceso/actions.ts:65 defense-in-depth). Fleet scope now = BOTH user-facing onboarding gates drop domain check: (1) auth/callback login, (2) /solicitar-acceso submit. Submit MUST stay behind genuine-Google gate (authenticated session+sub), NOT open public — human match is the real gate. Other 4 domain consumers untouched. pluto/venus checking their own request-submit path. One coherent change per app.
-
Addendum (mars MARS-518): request flow has TWO domain-gated steps in mars — solicitar-acceso submit (actions.ts:65) + solicitar-acceso/completar (actions.ts:185). Both fold under genuine-Google gate. Forwarded to pluto/venus to check for a second-step/completar equivalent. 4 non-onboarding consumers stay domain-gated.
-
Correction (mars): completar is NOT a fold-in — HMAC signed-link, no Google session, so a Google-sub gate is impossible; its domain check is data-integrity on the email field value (leave it, same class as admin/import guards). MARS final scope = 2 real-session gates only: callback login + solicitar-acceso submit. Forwarded to pluto/venus (don't Google-gate a signed-link completion step). Mars coder push-ready pending audit delta-OK.
-
PLUTO-609 LIVE+CLOSED: 6726f09 v2.20.15, Class-A audit PASS + coder PTD PASS (live version-match, deploy READY, 0 runtime errors 40m). Pluto onboarding-gate inventory: 1 submit + 2 completar, none had a domain gate beyond the already-non-blocking callback check (now removed). 4 non-onboarding consumers untouched, canonical index unaffected. VENUS-281 audit PASS, coder implementing. MARS-518 push-ready pending audit delta. 1 of 3 live.
-
MARS-518 LIVE+CLOSED: ead337b/v2.41.0 (logic) + 7b200b8/v2.41.1 (copy). Shipped = 2 real-session gates via shared isGenuineGoogleUser (identities[].provider=google + non-empty sub, fail-closed, no auto-create): auth/callback login + solicitar-acceso submit. Untouched: completar (signed-link data-integrity guard), admin create/email-change, import validation, outbound guard, email-domains.ts + systemSettings. audit design-OK + PASS:7b200b8, Class-A PTD PASS, live-version 2.41.1 confirmed. 2 of 3 live (pluto+mars); venus VENUS-281 implementing.
-
VENUS-281 LIVE+CLOSED: 6266971 v1.1.0. Login + submitAccessRequest now genuine-Google via isGenuineGoogleSession (provider+sub); domain allowlist detached from those 2 gates only; non-Google -> signOut + /no-autorizado; dead reason=email-domain branch removed. Completar (altEmail only) + 4 non-onboarding consumers untouched. audit design+diff PASS, Class-A PTD clean. CAVEAT: live auth path not exercised post-deploy (static/build verified only). ALL 3 LEGS LIVE (pluto 6726f09, mars 7b200b8, venus 6266971). Code complete. Remaining: commons §Auth doc fix tail item.
-
Pluto gate divergence found (pm-pluto-cc): pluto's callback has NO explicit provider/sub check — relies on Supabase Google-only provider config (config-only invariant; a future 2nd provider would silently open the gate). Mars/venus enforce identities[].provider=google + non-empty sub in code. RULING (b): pluto files a follow-up (PLUTO-N, Class-A, plan-first+audit) to add the explicit check, fail-closed — fleet-uniform code-enforced gating over implicit config invariant. Commons §Auth states the explicit check as the STANDARD; PLUTO-N closes pluto's code gap. All 3 PMs confirmed the doc rewrite. Awaiting: coder-mars-cc doc landing + PLUTO-N child/SHA.
-
Commons §Auth rewrite LANDED by coder-mars-cc: pensanta-websites SHA c4fe8be (canonical shared dir, symlink-read). Incorporates: explicit identities[].provider=google + non-empty sub as fleet standard/fail-closed (ruling b), pluto alignment noted in-flight as PLUTO-610; per-app landings worded to shipped reality (mars /login?error=not-google + unmatched-no-profile→/solicitar-acceso, venus /no-autorizado, pluto per-app); no auto-create, login≠access, userRoles real gate; /solicitar-acceso submit genuine-Google-gated; HMAC completion stays domain-checked (data-integrity); allowedEmailDomains retained non-login; EVO-59 domain-as-login-gate marked superseded. EVO-68 remaining: PLUTO-610 explicit-check follow-up (only open tail).
-
PLUTO-610 LANDED: b85dd4b v2.20.16, audit-pluto-ca post-deploy PASS. Explicit fail-closed genuine-Google gate now in pluto callback (all logins) + submitAccessRequest, matching mars/venus. ALL TAILS CLOSED. EVO-68 complete: mars 7b200b8, pluto 6726f09+b85dd4b, venus 6266971, commons doc c4fe8be. Login gates on real Google identity fleet-wide, domain allowlist retained for non-login uses only, no auto-create, human-match preserved.
-
status=done
decision
4w ago by wi-cli-venus
4w ago
2026-07-19 06:21