Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Readiness probe can't pass Access on a Custom-Domain-only Worker

Offen
  • Stimmt etwas nicht?
#619 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
48/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
devops

Rechercherichtung

Start in packages/deploy-cloudflare/src/version.ts at the readiness probe and guardedReadinessHeaders locations cited in the issue; compare the staged custom-route and first-deploy bootstrap paths with the existing test that prevents credentials from leaking to custom routes. Decide how the probe can authenticate safely for a Custom-Domain-only Worker, then add coverage for that behavior. Done means staged deploys can verify readiness with the intended Access setup while preserving the existing credential-scope protections.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Thanks for Void! I ran into what looks like a gap in the staged deploy flow.

Summary

If a Worker is served only on a Custom Domain behind Cloudflare Access (workers_dev: false, preview_urls: false), a staged void deploy can't pass the readiness probe. Access credentials are only sent to workers.dev hosts, so Access blocks the probe and the deploy rolls back. The error suggests setting CF_ACCESS_CLIENT_ID / CF_ACCESS_CLIENT_SECRET, but on this path they aren't sent.

Use case

I'm deploying an internal dashboard that only staff should reach. All our internal tools live under *.internal.example.com, and one wildcard Access application in front of that hostname applies the same SSO policy to every tool. The app also checks the Access JWT's audience, so it only trusts that one application.

I turned off workers_dev and preview_urls so the Worker has exactly one way in. A workers.dev URL is outside the wildcard. It would need its own Access application, with a second policy to keep in sync and a different audience for the app to accept. Without one, the app is public. Cloudflare recommends a route or Custom Domain over workers.dev for production Workers, so this seemed like the expected setup.

Repro

// void.config.ts
export default defineConfig({
  cloudflare: {
    routes: [{ pattern: 'dashboard.internal.example.com', custom_domain: true }],
    workers_dev: false,
    preview_urls: false,
  },
})
  1. Protect *.internal.example.com with an Access application whose policy admits a service token.
  2. Set CF_ACCESS_CLIENT_ID and CF_ACCESS_CLIENT_SECRET to that token.
  3. Run void deploy --platform cloudflare on a Worker that already has a deployed version.
deploy: Cloudflare Access blocked the uploaded Worker Version readiness probe.
For CI, set CF_ACCESS_CLIENT_ID and CF_ACCESS_CLIENT_SECRET to an admitted service token.

The same credentials work when sent manually:

curl -H "CF-Access-Client-Id: $CF_ACCESS_CLIENT_ID" \
     -H "CF-Access-Client-Secret: $CF_ACCESS_CLIENT_SECRET" \
     https://dashboard.internal.example.com/__void/ready
# {"ready":true,"versionId":"..."}

What I found

With no preview URL, activateCloudflareVersion stages the new version at 0% and probes the custom route with Cloudflare-Workers-Version-Overrides, but leaves the Access headers off:

This looks intentional. 6ea0b4699 added a test asserting the headers are not sent to a custom route ('must-not-leak'), which makes sense, since a route hostname isn't guaranteed to reach this Worker. The side effect is that a Custom-Domain-only Worker has no hostname where the probe can authenticate.

Workaround: --atomic (or deploy.cloudflare.mode: "atomic"). It deploys, but skips the pre-traffic check and exits with "the atomic Worker deployment is live, but /__void/ready could not be verified".

Possible directions

Not sure which fits Void's security model best, so here are the options I could see:

  1. Opt-in origin. Let the user name one origin that may receive the readiness credentials, similar to how VOID_ACCESS_ORIGIN scopes platform credentials. With nothing set, the current behavior stays the same.
  2. Custom Domains automatically. Send the headers when the probe host comes from a custom_domain: true route. One caveat: per Cloudflare's docs, a Route on the same hostname takes precedence over a Custom Domain, so this may need a route check first.
  3. Error message only. For a custom-route probe, point to --atomic instead of CF_ACCESS_CLIENT_*.

Happy to put together a PR if one of these sounds right.

void 1.2.1, @void/deploy-cloudflare 1.2.1. The same code is still on main (246e186, after v1.3.0).

Vorherrschende Sprache
TypeScript
Sterne
580
Forks
56
Ø Merge
11 Std. 23 Min.
Gemergte PRs (30 T.)
153

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus voidzero-dev/void

Alle Issues in voidzero-dev/void

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.