feat(auth): env-gate email/password and Google hd

[aiandwebservices-cyber]

Summary

Opts into email/password auth and optional Google hosted-domain (hd) via environment flags. Defaults are unchanged: email/password stays disabled and Google hd still applies when a workspace domain is configured.

Changes

• EMAIL_PASSWORD_ENABLED — set to true/1 to enable email/password sign-in
• GOOGLE_DISABLE_HD — set to true/1 to omit the Google hosted-domain restriction

Deploy notes (aisales)

1. Set EMAIL_PASSWORD_ENABLED=true
2. Set GOOGLE_DISABLE_HD=true
3. Redeploy

Other environments can leave both unset and keep current behavior.

---

Summary by cubic

Adds env flags to opt into email/password auth and to disable Google hosted-domain filtering. Defaults stay the same; nothing changes unless you set the flags.

• New Features

  • EMAIL_PASSWORD_ENABLED: enables email/password sign-in when set to true or 1.
  • GOOGLE_DISABLE_HD: removes the Google hd restriction when set to true or 1.

• Migration

  • For aisales: set EMAIL_PASSWORD_ENABLED=true and GOOGLE_DISABLE_HD=true, then redeploy. Other envs can leave both unset.

^{Written for commit 2212e3c. Summary will update on new commits.}

[vercel]

@aiandwebservices-cyber is attempting to deploy a commit to the Comp AI - PoC Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Retargeted this onto main.

release is the default branch so that a plain clone runs the last tagged release, but nothing merges into it — it is fast-forwarded onto the tag by the Release workflow and that is all. Changes go to main, and reach release when a release is cut.

Nothing is wrong with your branch. If the diff now shows commits that are already on main, rebase and force-push:

git fetch origin main
git rebase origin/main
git push --force-with-lease

[cubic-dev-ai]

2 issues found across 2 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="packages/auth/src/auth.ts">

<violation number="1" location="packages/auth/src/auth.ts:77">
P2: Enabling email/password for the first time via EMAIL_PASSWORD_ENABLED introduces an account-linking edge case. account.accountLinking.trustedProviders still lists only GOOGLE and MICROSOFT, not the email/password ("credential") provider. Better Auth auto-links a provider to an existing user by email only when the provider is in trustedProviders (or supplies email_verified); email/password does not satisfy that. So once a workspace user has an account created via Google, signing in later with email/password on the same address won't auto-link and can surface an "unable to link account" / conflicting-account flow. Worth deciding explicitly how this should behave before rolling the flag out on the aisales deploy. If email/password should be treated as the same identity, add the credential provider id to trustedProviders; otherwise confirm the manual-linking UX is acceptable and document it.</violation>
</file>

<file name="packages/auth/src/env.ts">

<violation number="1" location="packages/auth/src/env.ts:74">
P1: Turbo-managed deployments silently ignore both opt-ins, leaving email/password disabled and the Google hosted-domain restriction enabled even when the deploy notes set these variables. Adding both names to the root `globalPassThroughEnv` (or every relevant task's pass-through list) would make the runtime flags available.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Turbo-managed deployments silently ignore both opt-ins, leaving email/password disabled and the Google hosted-domain restriction enabled even when the deploy notes set these variables. Adding both names to the root globalPassThroughEnv (or every relevant task's pass-through list) would make the runtime flags available.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/auth/src/env.ts, line 74:

<comment>Turbo-managed deployments silently ignore both opt-ins, leaving email/password disabled and the Google hosted-domain restriction enabled even when the deploy notes set these variables. Adding both names to the root `globalPassThroughEnv` (or every relevant task's pass-through list) would make the runtime flags available.</comment>

<file context>
@@ -65,6 +70,10 @@ export const env = {
 	trustedOrigins: [...new Set([...appUrls, apiUrl])],
 	isProduction: process.env.NODE_ENV === "production",
+	/** Opt-in: set EMAIL_PASSWORD_ENABLED=true on a deploy to allow email/password auth. */
+	emailAndPasswordEnabled: flag("EMAIL_PASSWORD_ENABLED"),
+	/** Opt-in: set GOOGLE_DISABLE_HD=true to omit Google hosted-domain restriction. */
+	googleDisableHd: flag("GOOGLE_DISABLE_HD"),
</file context>

[cubic-dev-ai]

P2: Enabling email/password for the first time via EMAIL_PASSWORD_ENABLED introduces an account-linking edge case. account.accountLinking.trustedProviders still lists only GOOGLE and MICROSOFT, not the email/password ("credential") provider. Better Auth auto-links a provider to an existing user by email only when the provider is in trustedProviders (or supplies email_verified); email/password does not satisfy that. So once a workspace user has an account created via Google, signing in later with email/password on the same address won't auto-link and can surface an "unable to link account" / conflicting-account flow. Worth deciding explicitly how this should behave before rolling the flag out on the aisales deploy. If email/password should be treated as the same identity, add the credential provider id to trustedProviders; otherwise confirm the manual-linking UX is acceptable and document it.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At packages/auth/src/auth.ts, line 77:

<comment>Enabling email/password for the first time via EMAIL_PASSWORD_ENABLED introduces an account-linking edge case. account.accountLinking.trustedProviders still lists only GOOGLE and MICROSOFT, not the email/password ("credential") provider. Better Auth auto-links a provider to an existing user by email only when the provider is in trustedProviders (or supplies email_verified); email/password does not satisfy that. So once a workspace user has an account created via Google, signing in later with email/password on the same address won't auto-link and can surface an "unable to link account" / conflicting-account flow. Worth deciding explicitly how this should behave before rolling the flag out on the aisales deploy. If email/password should be treated as the same identity, add the credential provider id to trustedProviders; otherwise confirm the manual-linking UX is acceptable and document it.</comment>

<file context>
@@ -72,7 +74,7 @@ export const auth = betterAuth({
 
 	emailAndPassword: {
-		enabled: false,
+		enabled: env.emailAndPasswordEnabled,
 	},
 
</file context>