fix: request Drive scope in gwcli configure#48
Merged
Conversation
The live consent path (`gwcli configure` -> ConfigureAuth -> NewAuthenticator) built the OAuth consent URL from `authScopes` (oauth.go), which omitted `https://www.googleapis.com/auth/drive`. A freshly-configured OAuth token therefore never carried the Drive scope, so every `drive *` / `artifacts download` command failed with insufficient scope, and there was no consent path that requested Drive at all. The codebase had three divergent scope definitions, which masked the bug (two of them *did* list Drive but were unreachable dead code): - `authScopes` (oauth.go) - the only one that runs; no Drive - `scope` const (connection.go) - only used by dead `auth()` - inline list in `oauth2Config` - cosmetic at runtime; divergent Fix and consolidate to a single source of truth: - Add `drive.DriveScope` to `authScopes` (the actual fix) and rewrite the comment to explain installed-app OAuth is not all-or-nothing but Google won't add scopes to an already-issued token, so everything must be bundled on the consent screen. The service-account DWD path still requests Drive separately and is unaffected. - `oauth2Config` now reuses `authScopes` instead of its own hardcoded list, so the lists can't silently diverge again. - Delete the dead OAuth-configure cluster (configure.go: Configure / auth / makeConfig / readConf / readLine, the `scope` and `accessType` consts) that the real `ConfigureAuth` flow never invokes. - Update TestNewAuthenticatorScopes to assert Drive is requested. Existing OAuth users must re-run `gwcli configure` to re-consent (Google does not grant new scopes to an already-issued token.json). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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.
Problem
gwcli configurenever asks for the Drive scope, so everydrive */artifacts downloadcommand fails with insufficient scope on a freshlyconfigured account — and there is no consent path that requests Drive at all.
The live consent path is:
gwcli configure→runConfigure→ConfigureAuth→NewAuthenticator→ builds the consent URL fromauthScopes(oauth.go).authScopeslisted gmail.modify, gmail.settings.basic, gmail.labels, tasks, calendar — no Drive.Why it was hard to see
Three divergent scope definitions existed; the two that did include Drive were unreachable dead code:
authScopes(oauth.go)scopeconst (connection.go)auth()oauth2ConfigThe reasoning in the old
authScopescomment ("Drive requested separately because DWD token exchange is all-or-nothing") is correct for service accounts but was wrongly applied to the installed-app OAuth flow, where every scope must be bundled onto the one consent screen (Google won't add scopes to an already-issued token).Changes
drive.DriveScopetoauthScopes— the actual fix; comment rewritten to explain the installed-app vs. service-account distinction. The service-account DWD path still requests Drive separately and is unaffected.oauth2Confignow reusesauthScopesinstead of its own hardcoded list — single source of truth, can't silently diverge again.configure.go:Configure/auth/makeConfig/readConf/readLine; thescopeandaccessTypeconsts) that the realConfigureAuthflow never invokes.TestNewAuthenticatorScopesnow asserts Drive is requested.Migration
Existing OAuth users must re-run
gwcli configureto re-consent — Google does not grant new scopes to an already-issuedtoken.json. (This is already documented in CLAUDE.md/README.)Testing
go build ./...,go vet ./...,go test ./...— all pass.🤖 Generated with Claude Code