feat(auth): admin allow-list overrides allow_registration:false#12
Merged
Merged
Conversation
A superuser-managed client-domain allow-list (admin "Allowed individual emails" / "Allowed email domains") now also acts as an explicit registration grant: a new social user whose exact email — or whose email domain — is listed may sign in even when the service config has allow_registration:false. Previously the registration gate (social-login.service) only ever consulted the signed config and never the admin DB allow-list, so a whitelisted-but-unregistered user was blocked before the list was ever read. - New `isEmailAdminAllowedForRegistration` (login-domain-policy.service): reads the client domain's allowedEmails/allowedEmailDomains on the BYPASSRLS admin client; empty list grants nothing. Client-domain level only (a brand-new user has no org/team membership yet). - Wired into the new-user gate in loginWithSocialProfile as an explicit override, alongside the existing superuser-bootstrap exception. - Gate 2 (assertEmailDomainAllowedForLogin) already admits these users since their email/domain is in the same list, so both gates agree. - Admin help text updated to state the list doubles as an invite allow-list. Tests: +1 social-login (allow-list admits new user under reg:false) and +5 login-domain-policy (email/domain match, no match, empty, missing domain). Full API suite 531 passed; typecheck/lint/build green. Co-Authored-By: Claude Opus 4.8 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Makes the admin "Allowed individual emails" / "Allowed email domains" lists do what they intuitively imply: an explicit invite allow-list that lets a listed person sign in even when the service has
allow_registration: false.The gap this closes
The registration gate (
social-login.service.ts) only ever consulted the signed config (allow_registration,allowed_registration_domains) — it never read the admin-managed DB allow-list. So a whitelisted-but-unregistered email was blocked at registration before the list was ever looked at. (The list was only enforced as a restriction on already-authenticated users.)Change
isEmailAdminAllowedForRegistration(login-domain-policy.service.ts): reads the client domain'sallowedEmails(exact) +allowedEmailDomains(email domain) on the BYPASSRLS admin client. Empty list ⇒ grants nothing. Client-domain level only (a brand-new user has no org/team membership yet).loginWithSocialProfileas an explicit override, next to the existing first-superuser-bootstrap exception.assertEmailDomainAllowedForLogin) already admits these users (their email/domain is in the same list), so both gates agree — no lock-out surprise.Verification
reg:false), +5 policy (exact email, email domain, no match, empty lists, missing domain).🤖 Generated with Claude Code