Skip to content

fix: support client aliases for subdomain email accounts#523

Open
DrBaher wants to merge 1 commit intosteipete:mainfrom
DrBaher:fix/client-alias-auth-subdomain-email
Open

fix: support client aliases for subdomain email accounts#523
DrBaher wants to merge 1 commit intosteipete:mainfrom
DrBaher:fix/client-alias-auth-subdomain-email

Conversation

@DrBaher
Copy link
Copy Markdown

@DrBaher DrBaher commented Apr 23, 2026

Problem

When using gog auth add with a client alias for an account whose email has a subdomain (e.g. user@sub.company.ai), auth fails with:

authorized as user@sub.company.ai, expected company.ai

This affects any Google Workspace account on a subdomain domain (e.g. baher@medicus.ai using client alias baher.ai). Two bugs combine to cause this:

  1. auth_add.go: The OAuth-authorized email is compared against the alias name, which never matches a bare client name, so the token is never saved.
  2. clients.go: ResolveClientForAccount treats any input without @ as a malformed email with no domain, falling through to DefaultClientName instead of treating it as a direct client name.

Fix

  • auth_add.go: Skip the email match check when c.Email has no @ — the caller is intentionally using a client alias, not an email address.
  • clients.go: Treat any input without @ as a direct client name rather than attempting email/domain parsing.

Usage after fix

# One-time setup in config.json:
# { "account_clients": { "user@sub.company.ai": "company.ai" } }

gog auth add company.ai --services gmail,calendar,drive,...
# sign in as user@sub.company.ai in the browser

gog gmail search "newer_than:1d" --account user@sub.company.ai  # works

Tests

Added two new test cases:

  • TestAuthAddCmd_ClientAliasSkipsEmailCheck — verifies auth succeeds when a client alias is passed
  • ResolveClientForAccount/client name without @ is used as-is — verifies bare client name is returned directly
  • ResolveClientForAccount/subdomain email routes via account_clients mapping — verifies subdomain email routing via config

All existing tests pass.

When gog is configured with a client alias (e.g. 'company.ai') for an
account whose email has a subdomain (e.g. user@sub.company.ai), auth
and token resolution would fail because:

1. auth add: the email match check compared the OAuth-authorized email
   against the alias name, which never matched, aborting before saving
   the token.
2. ResolveClientForAccount: a bare string with no '@' was treated as an
   email with no domain, falling through to DefaultClientName instead of
   being used as the client name directly.

Fix:
- In auth_add.go: skip the email match check when c.Email has no '@',
  as the caller is intentionally using a client alias.
- In clients.go: treat any input without '@' as a direct client name
  rather than attempting email/domain parsing.

This allows workflows like:
  gog auth add company.ai --services gmail,...
  # sign in as user@sub.company.ai
  gog gmail search ... --account user@sub.company.ai  # works via account_clients config

Fixes auth for Workspace accounts on subdomain domains (e.g. medicus.ai).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant