Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Self-hosted platform: derive the R2 upload keys from the runtime API token

Đang mở
  • Có gì không ổn?
#426 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
34/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
github, typescript
Lĩnh vực
backend, cloud

Hướng nghiên cứu

Start with platform-lifecycle.ts, platform-management.ts, and platform-installer-secrets.ts; trace how runtime tokens and R2 credentials reach createPlatformInstallationSecrets and installPlatform. Check the token verification flow against platform/packages/api/src/email/cf-customer.ts and add coverage for both fallback directions, fresh installs, and token rotation. Done means derived credentials follow the specified precedence and recovery rules, with the docs updated and the Cloudflare token ID and presigned PUT behavior verified.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

enhancement

Problem

A self-hosted platform install asks for two extra pasted values on a separate
Cloudflare page: the R2 Access Key ID and Secret Access Key
(packages/void/src/cli/platform-lifecycle.ts, the R2 block after the GitHub
OAuth prompts; page platformSetupPages(plan).r2 in platform-setup.ts).
The keys are only used by the API Worker to presign direct-to-R2 asset PUTs
(platform/packages/api/src/routes/deploy.ts presignAssetPut,
platform/packages/api/src/r2-presign.ts). They are not checked at install time,
so a wrong pair only fails at the first void deploy --platform void that
uploads assets (packages/void/src/cli/direct-r2-upload.ts, raw
R2 PUT failed for <path> (<hash>): 403).

Cloudflare documents that an API token can act as an S3 key pair:
Access Key ID = the token ID, Secret Access Key = SHA-256 hex of the token value
(https://developers.cloudflare.com/r2/api/tokens/). The runtime token already
has Account → Workers R2 Storage → Edit, and the API Worker already holds it as
CF_API_TOKEN, so deriving the pair adds no new permission to any Worker.

Proposed design

fresh interactive or CI install
  runtime token verified ──▶ GET /user/tokens/verify (fallback /accounts/:id/tokens/verify)
                           ──▶ r2AccessKeyId = result.id
                               r2SecretAccessKey = sha256hex(runtime token)
  explicit VOID_PLATFORM_R2_ACCESS_KEY_ID + _SECRET_ACCESS_KEY pair still wins

upgrade / repair with a new VOID_PLATFORM_RUNTIME_CLOUDFLARE_API_TOKEN
  recovery r2SecretAccessKey == sha256hex(recovery cloudflareApiToken)?  (or no recovery)
     yes ──▶ derive again, update R2_* Worker secrets together with CF_API_TOKEN
     no  ──▶ keep the separately supplied pair
  • PlatformCloudflareClient.apiTokenId(accountId): token-verify lookup, returns a
    non-empty id without whitespace, otherwise throws.
  • platform-installer-secrets.ts: platformR2SecretFromToken,
    platformR2KeysFollowRuntimeToken(recovery), platformR2CredentialsFromRuntimeToken.
  • Lifecycle: remove the R2 page and both prompts; derive after the runtime token
    is verified.
  • platform-management.ts: derive on runtime-token rotation when the saved
    pair was derived from the previous token.
  • Docs: credentials.md (R2 section), ci.md (R2 rows optional), maintenance.md
    (rotation replaces derived keys; recreating the API needs R2 values only for
    a separate R2 token), development/runtime.md (drop R2 from needed inputs).

Problems to fix in this design before implementing

  1. Order in platform-management.ts: the keys cannot be derived both before
    createPlatformInstallationSecrets and after the runtime-token preflight, because
    the preflight (resolvePlatformRuntimeTokenToPreflight(plan, secrets)) reads the
    result of createPlatformInstallationSecrets. Derive before
    createPlatformInstallationSecrets and leave the preflight where it is; the
    token-verify call already rejects an invalid token.
  2. Token-ID lookup order: trying account verify first and falling back only on
    401/403/404 is not enough. What /accounts/:id/tokens/verify returns for a user token is
    unverified (it may be 400). Match
    platform/packages/api/src/email/cf-customer.ts verifyToken (user verify
    first, then account verify), or fall back on any 4xx except 429. Rethrow 5xx.
    Test both fallback directions.
  3. Precedence on a non-draft resume: configured() in the lifecycle returns
    values[key] || env when credentialSetup is false. Reading the env pair first
    in every mode flips that; with existingInstallation and no
    updateExistingWorkers, the live API Worker keeps its old R2 secret while
    recovery saves the env pair, and later hash matching compares the wrong value.
    Apply the env pair only when credentialSetup is true; otherwise keep the
    checkpoint values.
  4. "Set both or neither": a new error for a half-set env pair can break a resume
    that works today (one variable set, the other from the checkpoint). Apply the
    check only on a fresh install (credentialSetup).

Tests this design needs: derived values reach createPlatformInstallationSecrets
and installPlatform on a fresh interactive install (token id from a spied
apiTokenId, secret = sha256 of the runtime token); the half-set env pair
error; upgrade with a rotated runtime token updates R2_ACCESS_KEY_ID /
R2_SECRET_ACCESS_KEY only when the saved pair was derived.

Unverified before merge

  • /user/tokens/verify or /accounts/:id/tokens/verify returns id for an
    account-owned runtime token (cfat_…), and a presigned PUT signed with the
    derived pair succeeds on the e2e account.
  • Without recovery data, a rotation would also rewrite a separately supplied
    pair. It keeps working (the runtime token has R2 Edit), but it changes
    "only supplied values replace live credentials"; docs must say so.

Related, separate

An install-time R2 key check would also catch a wrong pasted pair before the
first deploy (today it surfaces as a raw 403 from direct-r2-upload.ts).

🤖 Generated with Claude Code

https://claude.ai/code/session_0123r5HnanmW2VUrZ7VWDufH

Ngôn ngữ chính
TypeScript
Star
402
Fork
32
Merge trung bình
13 giờ 14 phút
Pull request đã merge (30 ngày)
73

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của voidzero-dev/void

Tất cả issue của voidzero-dev/void

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.