History

Drop the e2e assertion contradicting the Google scope allowlist (#1700)

Rhys Sullivan committed 2 months ago

Commit 4817fa11 parent a5800a11 file · +8 −3Browse files

Unified · Split

e2e/scenarios/first-party-oauth.test.ts+8−3
@@ -221,9 +221,14 @@ scenario( · 220 unmodified lines
221221 expect(google.origin.allowedScopes).toContain(
222222 "https://www.googleapis.com/auth/meetings.space.readonly",
223223 );
224− expect(google.origin.allowedScopes).not.toContain(
225− "https://www.googleapis.com/auth/gmail.modify",
226− );
224+ // `gmail.modify` stays in the host-enforced allowlist on purpose: a
225+ // connection created before the full-Gmail review still declares it, and
226+ // `resolveFirstPartyScopes` filters discovered scopes through this list,
227+ // so dropping it would break those reconnects — as the legacy-spec case
228+ // further down this file asserts. The invariant that new Gmail presets
229+ // request `mail.google.com` instead lives in the preset unit tests
230+ // (packages/plugins/openapi/.../presets.test.ts), which is where the
231+ // request-side scope choice is actually decided.
227232 expect(google.origin.allowedScopes).toContain("https://mail.google.com/");
228233 expect(google.origin.allowedScopes).toContain(
229234 "https://www.googleapis.com/auth/gmail.settings.basic",