Repository navigation
feat: support wrangler OAuth credentials for deploy --remote - #3
Merged
Merged
Conversation
Previously `deploy --remote` required a CLOUDFLARE_API_TOKEN. Cloudflare's REST API accepts an OAuth access token as a Bearer token identically to an API token, so we can authenticate with the credentials `wrangler login` already stores on disk. - CloudflareClient now takes a `getToken()` provider instead of a static token, fetched per request so a refreshed token is picked up mid-run. - New src/auth.ts reads wrangler's default.toml (mirroring its config-path resolution), returns the access token while valid, and refreshes via the OAuth token endpoint when expired — persisting the rotated token back to the same file so wrangler stays in sync. - deploy.ts prefers an explicit --api-token / CLOUDFLARE_API_TOKEN and falls back to OAuth; run.ts accepts either for the --remote credential check. API-token and CI behavior are unchanged. account_id is still required. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Addresses review feedback on the wrangler OAuth support: - Guard against a malformed token-endpoint response: a 200 missing access_token/expires_in now throws a clear "wrangler login" error instead of crashing on `new Date(NaN).toISOString()` or emitting a `Bearer undefined` header. - Persist refreshed tokens via in-place line replacement so comments, the scopes line, and any future wrangler fields survive the rewrite (the previous serializer reconstructed the file from known keys only). - Add `--no-persist-token` to opt out of writing the refreshed token back to wrangler's config (e.g. read-only credential dirs). Co-Authored-By: Claude Opus 4.8 (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
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.
Previously
deploy --remoterequired a CLOUDFLARE_API_TOKEN. Cloudflare'sREST API accepts an OAuth access token as a Bearer token identically to an
API token, so we can authenticate with the credentials
wrangler loginalready stores on disk.
getToken()provider instead of a statictoken, fetched per request so a refreshed token is picked up mid-run.
resolution), returns the access token while valid, and refreshes via the
OAuth token endpoint when expired — persisting the rotated token back to
the same file so wrangler stays in sync.
back to OAuth; run.ts accepts either for the --remote credential check.
API-token and CI behavior are unchanged. account_id is still required.
Verification (live, throwaway env)
Ran self-cleaning create→delete probes using real
wrangler loginOAuth credsagainst the
nobileaccount to settle whether the login scopes cover resourcesoblaka provisions (the open question was D1/R2/Vectorize, which have no dedicated
scope in wranglerʼs login set):
200200200200201200403(product not enabled on this account)Cloudflare authorizes them via account membership.
403was a product-not-enabled message, not an auth rejection, so it isnot conclusive; indirect evidence (a product-level error rather than a 9109-style
auth error) suggests the token is scope-accepted. Not retested on an R2-enabled
account.
GET /accounts→200confirms the token-provider path end-to-end; cleanup left0 leftover resources.