Introdução
A API de pré-visualização de uma equipe de suporte está informando a configuração ativa, e a execução de teste da manutenção rejeita a credencial de pré-visualização. O ambiente ativo continua funcionando. Sua tarefa é restaurar o isolamento da pré-visualização sem enfraquecer a autorização de manutenção nem alterar o comportamento do ambiente ativo.
Este desafio independente fornece um Worker pequeno, dois ambientes locais nomeados e credenciais sintéticas em uma VM nova. Aplique as práticas de configuração, carregamento de segredos e testes de runtime dos laboratórios guiados. Para obter sucesso, os dois ambientes locais devem atender ao contrato abaixo; depois, remova os servidores temporários e os arquivos de segredos. Aqui, os nomes preview e live descrevem ambientes de teste locais; este desafio não exige login nem implantação no Cloudflare.
Restaurar o isolamento da pré-visualização
Situação atual
O projeto preparado está em /home/labex/project/preview-drift. O Node 22.22.0, o Wrangler 4.131.1 local do projeto e o runtime de testes independente já estão instalados. Os servidores de desenvolvimento ainda não estão em execução. O handler fornecido implementa o endpoint público de saúde e uma execução de teste sintética da manutenção; o problema está na configuração pública do ambiente de pré-visualização e no carregamento da credencial.
Escopo
Trabalhe com wrangler.jsonc, src/index.js, .dev.vars.preview, .dev.vars.live e .gitignore. Inspecione o handler e a configuração para encontrar o contrato dos bindings. Os dois arquivos dotenv contêm credenciais aleatórias diferentes, usadas somente para testes. Você pode inspecionar os nomes das chaves sem exibir os valores. Mantenha as credenciais privadas nesta VM e fora do Git.
Execute o ambiente do Wrangler preview na porta de loopback 8080 e o ambiente live na porta 8081. Dê portas de inspeção diferentes aos runtimes simultâneos. Use os comandos comuns de desenvolvimento do Wrangler local do projeto; este desafio não cria recursos remotos. QUEUE_LABEL é uma string de exibição, não um serviço de filas.
Seu objetivo
Os dois ambientes locais devem expor sua identidade pública prevista e permitir a manutenção somente com a própria credencial configurada. A pré-visualização deve permanecer isolada do ambiente ativo, e o endpoint público de saúde existente, assim como o comportamento seguro em caso de falha, deve continuar disponível.
Critérios de aceitação
- GET
/healthretorna JSON com o statusok. A pré-visualização identifica o ambientepreviewe a filasandbox; o ambiente ativo identifica o ambientelivee a filaprimary. - Cada ambiente carrega sua própria credencial sintética por meio do binding
MAINTENANCE_TOKENdo handler. Mantenha os dois valores de credencial diferentes e fora do código-fonte e das variáveis públicas do Wrangler. Os arquivos dotenv locais continuam legíveis somente pelo usuário da VM e excluídos do Git. - POST
/maintenanceretorna 200 comoperation: dry-rune somente o nome do ambiente correspondente quando recebe uma credencial bearer válida daquele ambiente. Credenciais ausentes, inválidas ou pertencentes ao outro ambiente retornam 401 comerror: unauthorized. - Um segredo configurado ausente falha de forma segura, retornando 503 com
error: maintenance_unconfigured. GET/maintenancecontinua retornando 405 comerror: method_not_allowed; uma rota desconhecida continua retornando 404 comerror: not_found. - As respostas e os logs da aplicação não contêm valores de credenciais. Os dois servidores locais continuam em execução durante as duas verificações desta etapa. Não é necessário fornecer autorização na nuvem, fazer implantação, gerar relatório ou copiar um marcador de sucesso.
Dicas
Compare a origem de cada valor público
Leia as consultas ao ambiente no handler e compare-as com os objetos de ambiente nomeados em wrangler.jsonc. As variáveis de ambiente do Wrangler não são herdadas automaticamente. O ambiente selecionado por um runtime e os valores dentro desse ambiente são elementos separados.
Investigue uma resposta maintenance-unconfigured
Diferencie um binding configurado ausente de uma credencial recebida e rejeitada. Compare o nome do binding usado pelo handler com os nomes das chaves no arquivo dotenv específico do ambiente. A existência de um arquivo local não garante que ele defina o binding lido pelo handler. Depois de alterar a configuração, verifique novamente se o runtime está pronto.
Mantenha o comportamento do ambiente ativo e o limite de segurança
Teste o endpoint de saúde e a manutenção nos dois sentidos. Um token válido em um ambiente deve ser inválido no outro. A operação de manutenção fornecida é uma execução de teste, portanto uma solicitação corretamente autorizada não altera dados da aplicação.
Deixar o workspace limpo
Situação atual
Os ambientes locais reparados passaram nas verificações funcionais. Os processos de desenvolvimento e os arquivos de credenciais sintéticas ainda estão presentes nesta VM.
Escopo
Somente os jobs de desenvolvimento deste desafio nas portas 8080 e 8081, os arquivos .dev.vars.preview e .dev.vars.live e as variáveis do shell que contêm seus valores são temporários. Preserve o código-fonte reparado, a configuração, as dependências e os serviços do LabEx.
Seu objetivo
O projeto reparado continua disponível, sem nenhum servidor do desafio em execução e sem arquivos de segredos locais restantes.
Critérios de aceitação
- Nenhuma das portas 8080 e 8081 possui um servidor de desenvolvimento escutando.
- Nenhum arquivo de segredo
.dev.vars*ou.env*permanece no projeto do desafio. - Limpe as variáveis do shell usadas para as credenciais sintéticas. Esta é uma ação de limpeza do aprendiz; o backend não consegue inspecionar o estado do seu shell interativo.
- Preserve processos e arquivos não relacionados. Não há recursos na nuvem nem credenciais do Cloudflare para remover neste desafio exclusivamente local.
Dicas
Direcione os jobs que você iniciou
Use a lista de jobs do shell para identificar os dois processos de desenvolvimento do Wrangler. Os números dos jobs podem mudar depois que um servidor for reiniciado. A verificação funcional vem antes da limpeza; remover os segredos primeiro tornaria as verificações anteriores inconclusivas.
Resumo
Você rastreou a divergência da identidade da pré-visualização até os valores do ambiente nomeado e a falha de manutenção até o nome do binding da credencial. O reparo restaurou o isolamento da pré-visualização, mantendo o comportamento do ambiente ativo, o endpoint público de saúde e a autorização no servidor.
Os testes com credenciais ausentes, inválidas, de outro ambiente e válidas estabeleceram o limite de forma mais completa do que uma única resposta bem-sucedida. A limpeza final removeu os processos locais e os segredos sintéticos, preservando o projeto reparado.
