fix(wrangler): reject secrets-store secret values larger than 64 KiB#14020
Conversation
…aracters The CLI was accepting overly long values, returning a successful response, and listing the secret as if it were stored — but the Cloudflare API discards anything over 1024 characters, so any worker binding to that secret then fails at deploy time with a confusing "secret doesn't exist" error. The dashboard already enforces the same 1024 cap and never shows these orphaned secrets. Add `validateSecretValue` next to the existing `validateSecretName` and call it from both the `create` and `update` handlers (in the update case, only when a new value is actually being supplied — the command allows updating just scopes or comment). Cover the create path with a unit test mirroring the existing missing-field error tests. Fixes cloudflare#14018
🦋 Changeset detectedLatest commit: 63c9210 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
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 |
|
Codeowners approval required for this PR:
Show detailed file reviewers |
create-cloudflare
@cloudflare/deploy-helpers
@cloudflare/kv-asset-handler
miniflare
@cloudflare/pages-shared
@cloudflare/unenv-preset
@cloudflare/vite-plugin
@cloudflare/vitest-pool-workers
@cloudflare/workers-editor-shared
@cloudflare/workers-utils
wrangler
commit: |
|
Thank you very much for the PR @shiminshen 🙏 The API does not seem to actually enforce this cap, only the dashboard is, before reviewing your PR I need to check with the secret store team if that's intentional (besides that the changes here look good to me) |
|
Hi @shiminshen, I checked with the team and they did let me know that the limit has been increased to 64 KiB see: api docs Could you update the PR to respect this new upper limit? 🙏 |
The API limit was 1024 characters when this PR was opened, but the secrets-store team has since raised it to 64 KiB (65,536 bytes). Validate by UTF-8 byte length to match the API doc exactly -- character-length would under-count multi-byte unicode and let oversize values slip through.
|
Thanks for checking with the team @dario-piotrowicz! Updated in fe1e398:
|
dario-piotrowicz
left a comment
There was a problem hiding this comment.
Looks great to me! Thank you very much @shiminshen! 🙏
I just left one last comment, everything else beside that is great for me!
workers-devprod
left a comment
There was a problem hiding this comment.
Codeowners reviews satisfied
Co-authored-by: Dario Piotrowicz <dario.piotrowicz@gmail.com>
Fixes #14018
What this PR addresses
#14018 —
wrangler secrets-store secret createlets users create secrets longer than 1024 characters even though the Cloudflare API silently discards anything over the cap. The CLI claims success,secret listeven shows the secret, but any worker that binds to it then fails at deploy time with a misleading "secret doesn't exist" error. The dashboard already enforces the 1024-char cap and never shows these orphan secrets.What changed
packages/wrangler/src/secrets-store/commands.tsMAX_SECRET_VALUE_LENGTH = 1024and avalidateSecretValuehelper sitting next to the existingvalidateSecretName. The error message names the cap, the actual length received, and why the API rejects it, so the user can fix it without round-tripping through the dashboard.validateSecretValuefrom thecreatehandler after the value is gathered (args.valueor the interactive prompt).validateSecretValuefrom theupdatehandler only when a new value is being supplied — the command intentionally allows updating just scopes or comment without re-supplying the value.packages/wrangler/src/__tests__/secrets-store.test.ts— new test under the existingsecrets-store secret createdescribe block that sends a 1025-character value and asserts the new error message, mirroring the pattern of the existing missing-field error tests.patchtowrangler).Notes
client.tscreateSecret/updateSecretcalls instead, but kept it at the handler so the error is symmetrical with the existingvalidateSecretNamecall (which also runs at handler /validateArgstime, not at the API call site).