Skip to content

fix(features): single source of truth for OAuth scopes; dedup read scopes (#323)#347

Open
allenhutchison wants to merge 3 commits intomainfrom
fix/323-scope-drift-and-dedup
Open

fix(features): single source of truth for OAuth scopes; dedup read scopes (#323)#347
allenhutchison wants to merge 3 commits intomainfrom
fix/323-scope-drift-and-dedup

Conversation

@allenhutchison
Copy link
Copy Markdown
Contributor

Summary

  • setup-gcp.sh now sources its scope list from feature-config.ts via a small scripts/print-scopes.ts shim, replacing the hand-maintained SCOPES=(...) array that drifted out of sync. This was the root cause in Published GCP project missing .readonly scopes requested by default read feature groups #323 — the published GCP consent screen was missing the six .readonly scopes that feature-config.ts requests by default.
  • resolveFeatures no longer requests a <service>.readonly scope when the paired <service>.write group is enabled (the write scope already grants read access at the API level). Avoids prompting users for both drive and drive.readonly (etc.) on consent. Read tools are unaffected — only the redundant scope is dropped.
  • Two drift guards: a unit test asserts print-scopes.ts emits exactly getAllPossibleScopes(), and another asserts setup-gcp.sh has no inlined scope list.

Note: the published geminicli.com GCP project's consent screen was already updated out-of-band with the missing .readonly scopes. This PR closes the code/script side so the gap can't recur.

Test plan

  • npm run lint
  • npm run format:check
  • npm run build
  • npm test — 484 passing (41 in features/, up from 22)
  • npx ts-node --transpile-only scripts/print-scopes.ts outputs the 17 expected scopes including the six .readonly ones
  • Manual repro from Published GCP project missing .readonly scopes requested by default read feature groups #323 (clear WORKSPACE_CLIENT_ID / WORKSPACE_CLOUD_FUNCTION_URL, OAuth on a non-test-user account) shows the consent screen instead of "This app is blocked"

Closes #323

…opes when paired write enabled (#323)

- `setup-gcp.sh` now sources scopes from `feature-config.ts` via a small
  `scripts/print-scopes.ts`, eliminating the hand-maintained list that
  drifted and caused users to hit "This app is blocked."
- `resolveFeatures` skips a read group's scopes when its paired write
  group is enabled (the write scope grants read access at the API level).
  Avoids redundant `drive` + `drive.readonly` (etc.) consent prompts.
- Drift-guard tests assert `print-scopes.ts` emits `getAllPossibleScopes()`
  and that `setup-gcp.sh` has no inlined scope list.
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request centralizes OAuth scope management by dynamically generating the GCP consent screen registration list from the codebase, eliminating hardcoded values in setup-gcp.sh. It also introduces scope deduplication logic to avoid redundant permission prompts when write scopes are active. A review comment identifies a potential issue where environment warnings in the script output could be incorrectly parsed as scopes, suggesting a filter to only include valid URL strings.

Comment thread scripts/setup-gcp.sh
execFileSync('npx', ...) fails on Windows because npx is npx.cmd and
Node's spawn doesn't auto-resolve .cmd extensions without a shell.
execSync runs through the shell on every platform.
Address review feedback: ts-node stderr (Node deprecation warnings, etc.)
was captured into SCOPES_OUTPUT via 2>&1 and would have been surfaced to
the user as bogus OAuth scopes. Filter on the https:// prefix instead, and
fail loudly if filtering leaves zero scopes.
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.

Published GCP project missing .readonly scopes requested by default read feature groups

1 participant