feat(oauth): honor --project-id on the OAuth login path#743
Merged
Conversation
On the OAuth path the project was taken solely from the consent screen (scoped_teams[0]), silently ignoring --project-id. Now the flag is authoritative when the user granted access to it, and we fail loudly if they authorized a different project instead of capturing into the wrong one. Also forward it to the authorize URL as team_id so the consent screen can pre-select that project. Generated-By: PostHog Code Task-Id: db71c482-9c12-4f75-af93-fa23836280e5
🧙 Wizard CIRun the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands: Test all apps:
Test all apps in a directory:
Test an individual app:
Show more apps
Results will be posted here when complete. |
Extract the post-OAuth project selection into a pure resolveGrantedProject helper and unit-test it: no --project-id falls back to scoped_teams[0] (unchanged for the main integration flow and every other program), --project-id is honored when granted, and a different grant is flagged as a mismatch. Generated-By: PostHog Code Task-Id: db71c482-9c12-4f75-af93-fa23836280e5
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
2 participants
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
--project-idis already a global flag and is honored on the CI path, but on the interactive OAuth path it was silently dropped — the project came solely fromtokenResponse.scoped_teams[0](whatever the user picked on the consent screen). So a caller that knows the target project (e.g. PostHog's in-app MCP analytics onboarding) couldn't actually pin it, and if the user picked the wrong project on consent we'd silently capture into it.Changes
In
askForWizardLogin(src/utils/setup-utils.ts):projectIdand use it as authoritative when the user granted access to it (scoped_teamsincludes it).--project-idwas passed but the user authorized a different project, fail loudly with a clear message instead of silently using the wrong one.scoped_teams[0]when no--project-idis given (unchanged behavior).In
performOAuthFlow(src/utils/oauth.ts):projectIdto the authorize URL asteam_id, so the PostHog consent screen can pre-select that project (paired with a dotcom change that reads the hint). Harmless against an older backend that ignores the param.Test plan
Agent-authored (PostHog Code); not manually run against a live OAuth flow. Automated checks:
tsc --noEmitclean for the changed files,prettier --checkpasses. Suggested manual verification: run an OAuth login with--project-id=<a project you belong to>and confirm the wizard targets it; with--project-id=<a project you don't grant>confirm it errors clearly rather than proceeding.LLM context
Authored with PostHog Code at Lucas's direction, as the wizard half of the MCP analytics "pin the project" work. Pairs with a dotcom PR that makes the OAuth consent screen pre-select the
team_idhint, and the in-app install command that now emits--project-id. The--project-idflag and its plumbing intoWizardSessionalready existed; the only gap was insideaskForWizardLogin, which dropped it on the non-CI branch.Addendum — example & expected behavior
What's expected once the full chain is live:
team_id=123in the authorize URL.123and instruments against it.--project-id, behavior is unchanged: it uses the granted project (scoped_teams[0]).Against an older PostHog backend (before the consent change deploys),
team_idis simply ignored and the user picks the project manually — so this is safe to merge/release independently.Companion PRs (PostHog/posthog)
team_idhint and pre-selects the project (the direct counterpart to this PR).--project-idthis PR consumes.