fix(gmail): use OAuth userinfo endpoint for From display name fallback#684
fix(gmail): use OAuth userinfo endpoint for From display name fallback#684malob wants to merge 1 commit intogoogleworkspace:mainfrom
Conversation
The People API fallback for resolving the From display name on Workspace accounts required people.googleapis.com to be enabled in the GCP project. When disabled, the 403 was misreported as "grant profile scope" even when the scope was already present (googleworkspace#644). Switch to the OAuth userinfo endpoint (oauth2/v2/userinfo), which only requires the userinfo.profile scope and no separately-enabled API. Log a note when the endpoint succeeds but returns no display name, making the silent degradation visible. Give GOOGLE_WORKSPACE_CLI_TOKEN users a context-appropriate tip instead of telling them to run gws auth login. Fixes googleworkspace#644
🦋 Changeset detectedLatest commit: dbba810 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
googleworkspace-bot
added
area: auth
area: core
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses an issue where the Gmail display name fallback mechanism failed for Workspace accounts due to an unnecessary dependency on the People API. By switching to the standard OAuth userinfo endpoint, the CLI now correctly handles display name resolution without requiring additional API enablement in the GCP project. The changes also improve error reporting and user guidance for authentication scopes. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request replaces the Google People API with the OAuth userinfo endpoint for retrieving Gmail sender display-name fallbacks, removing the requirement to enable the People API in GCP projects. It introduces context-aware tips for users based on whether they are using environment-based tokens or saved credentials and updates the internal fetching and parsing logic accordingly. I have no feedback to provide.
2 participants
Description
Fixes the From display name fallback for Workspace accounts where the sendAs identity has no display name configured. The previous fallback called the People API (
people.googleapis.com/v1/people/me), which requires the People API to be separately enabled in the GCP project. When it isn't enabled, the 403accessNotConfigurederror was misreported as "grant the profile scope" — even when theuserinfo.profilescope was already present in the token.Root cause
The People API has two prerequisites: the OAuth scope (
userinfo.profile) AND the API enabled in the GCP project console. The error handler at the oldfetch_profile_display_nameonly checked for 403 and assumed it meant "missing scope," which is wrong when the scope is granted but the API isn't enabled.The fix
Switch the fallback from the People API to the OAuth userinfo endpoint (
oauth2/v2/userinfo). This endpoint:userinfo.profilescope (no separately-enabled API){"name": "...", ...}at the top level (simpler response shape)auth_commands.rs)Other improvements
namefield (e.g. a freshly-provisioned account with no profile configured), a note is now printed to stderr. Previously this was completely silent — the user got no display name with no explanation.GOOGLE_WORKSPACE_CLI_TOKENusers now see a tip about setting a token with the profile scope, instead of being told to rungws auth login(which doesn't apply to them).fetch_profile_display_name→fetch_userinfo_display_name,parse_profile_display_name→parse_userinfo_display_nameto reflect the new endpoint.What this does NOT change
The primary display name path (sendAs identity lookup via
/users/me/settings/sendAs) is untouched. This fix only affects the fallback for Workspace accounts where sendAs returns an emptydisplayName. The token cache and auth flow are also unchanged.Verified
+send --draft— From header correctly shows display name, no spurious tip printed.Fixes #644
Checklist:
AGENTS.mdguidelines (no generatedgoogle-*crates).cargo fmt --allto format the code perfectly.cargo clippy -- -D warningsand resolved all warnings.pnpx changeset) to document my changes.