Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

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

Aberta
  • Algo errado?
#619 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
48/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
typescript
Domínio
devops

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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).

Linguagem predominante
TypeScript
Estrelas
580
Forks
56
Merge médio
11h 28min
PRs com merge (30d)
150

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de voidzero-dev/void

Todas as issues de voidzero-dev/void

Issues semelhantes

Mais issues de TypeScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.