René's URL Explorer Experiment

Title: feat(cli): add BigQuery Google OAuth authentication by tkislan · Pull Request #506 · deepnote/deepnote · GitHub

Open Graph Title: feat(cli): add BigQuery Google OAuth authentication by tkislan · Pull Request #506 · deepnote/deepnote

X Title: feat(cli): add BigQuery Google OAuth authentication by tkislan · Pull Request #506 · deepnote/deepnote

Description: Adds deepnote integrations auth, so a local deepnote run can execute SQL blocks against a big-query integration configured with authMethod: google-oauth. Today those blocks fail inside Python with a generic "not linked with a connected integration" message, because the synchronous env var generator emits no SQL_ variable for federated metadata. The CLI runs a PKCE authorization-code flow through Deepnote's existing OAuth proxy, exchanges the code locally, and stores the refresh token per integration under ~/.deepnote/federated-auth-tokens/. At run start it mints an access token for each federated integration a block that will actually execute references, and injects it as the SQL_ variable the generated Python reads. Chunks Seven commits, each independently reviewable; they are not independently shippable. Commit 1 0376fd7 PKCE, state, code exchange and refresh against Google's token endpoint 2 606d083 Per-integration token store, atomic writes, 0600 in 0700 3 09da370 Loopback callback server, plus two browser.ts prerequisite fixes 4 bf82bf1 The integrations auth command, CLI registration, completions 5 88e01bb getBigQueryOAuthSqlAlchemyInput in @deepnote/database-integrations 6 e1d336c The deepnote run credential gate and the deepnote lint false-positive fix 7 c1ae987 README and skills/deepnote references Plus 54a1163 and a473a4f, both from review feedback: extending the lint fix to run --context, and covering two run-level guarantees that had no test. Behaviour worth reviewing closely The gate runs before the execution engine. Ordering inside setupProject is now scope, interpreter, upstream block ids, credential gate, then the requirements check. A missing or stale credential fails the command with no kernel started and no block executed, so nothing the notebook would have done first can leave a side effect behind. Scoped to blocks that will actually execute, not the notebook. collectRequiredIntegrationIds is notebook-wide and stays that way for the API merge and the missing-integration check, but using it here would make deepnote run --block demand a browser login for an integration the run never touches. resolveUpstreamExecutionBlockIds is hoisted into setupProject so the gate and the execution agree on the block set by construction; it returns immediately without --block, so a normal run pays nothing. --dry-run contacts nothing and writes nothing. It reads the token store and compares the client fingerprint, and fails the same way a real run would if either is missing. The authorization-code grant is attempted exactly once, unlike the refresh grant. A code is single-use and a lost response is indistinguishable from an undelivered request, so a retry can replay a code Google has already consumed — which per RFC 6749 §4.1.2 lets Google revoke every token minted from it. The same invariant is defended one layer up by the loopback server's synchronous claim: nothing after a claim can settle the flow, because any page open in the user's browser can reach a loopback port. Bugs found and fixed during review Each was reproduced before being fixed, and each has a test that fails against the old code. One --domain produced two different hosts. redirectUri was interpolated while the start URL went through new URL(), which strips a default port and lowercases the host — so --domain deepnote.com:443 sent Google a redirect_uri the proxy never used, failing only after the user consented. A post-claim callback with a bad state killed the legitimate in-flight flow, burning the authorization code. The token store did not own version/integrationId: Omit is a structural supertype of StoredToken, so spreading the payload last let a caller reinstate them and write an entry readToken then rejects. The lint fix reached deepnote lint but not run --context, which runs the same check. Not done No end-to-end run against a real GCP OAuth client. Every Google and proxy interaction is exercised against a local stub server only. The --domain bug above is exactly the class this would catch. The two --block scope cases are verified at the resolver level and by manual execution, not by an automated run-level test. Deliberate exclusions are recorded rather than fixed: no integrations logout, no SSH tunnelling, no keychain encryption. Note that getEnvironmentVariablesForIntegrations already emits BQ_CLIENTSECRET for these integrations into the kernel environment. That is pre-existing generic behaviour for every integration type and is untouched here, but it is worth tracking separately. Verification pnpm test 3219 passed / 1 skipped / 181 files · pnpm typecheck exit 0 · pnpm biome:check clean on all source · pnpm prettier:check clean. New behaviour was mutation-tested rather than assumed: each assertion was checked against a deliberately broken implementation, and the survivors are documented in the test comments as understood non-gaps rather than papered over. Summary by CodeRabbit New Features Added integrations auth [id] for browser-based authentication of Google OAuth BigQuery integrations. Authentication credentials are stored locally and refreshed for local runs. Dry runs check stored credentials without contacting Google or refreshing tokens. Added shell completions for the authentication command. Local runs check credentials for integrations used by selected blocks; cloud runs are unaffected. Linting recognizes configured Google OAuth BigQuery integrations without checking stored credentials. Bug Fixes Improved browser-launch handling across platforms and credential validation and error reporting. Documentation Updated CLI help and guides with authentication steps, environment-file options, and local-run credential requirements.

Open Graph Description: Adds deepnote integrations auth, so a local deepnote run can execute SQL blocks against a big-query integration configured with authMethod: google-oauth. Today those blocks fail inside Python with ...

X Description: Adds deepnote integrations auth, so a local deepnote run can execute SQL blocks against a big-query integration configured with authMethod: google-oauth. Today those blocks fail inside Python with ...

Opengraph URL: https://github.com/deepnote/deepnote/pull/506

X: @github

direct link

Domain: github.com

Links:

Viewport: width=device-width