Introduction
L’API de prévisualisation d’une équipe de support renvoie la configuration de production, et son exécution à blanc de maintenance refuse l’identifiant de prévisualisation. L’environnement de production fonctionne toujours. Votre objectif est de rétablir la séparation de la prévisualisation sans affaiblir l’autorisation de maintenance ni modifier le comportement de la production.
Ce défi autonome fournit un petit Worker, deux environnements locaux nommés et des identifiants synthétiques dans une VM neuve. Appliquez les pratiques de configuration, de chargement des secrets et de test à l’exécution étudiées dans les laboratoires guidés. La réussite signifie que les deux environnements locaux respectent le contrat ci-dessous, puis que les serveurs temporaires et les fichiers de secrets sont supprimés. Ici, les noms preview et live désignent des environnements de test locaux ; ce défi ne nécessite ni connexion à Cloudflare ni déploiement.
Rétablir l’isolation de la prévisualisation
Situation actuelle
Le projet préparé se trouve dans /home/labex/project/preview-drift. Node 22.22.0, Wrangler 4.131.1 installé localement dans le projet et l’environnement d’exécution de test indépendant sont installés. Les serveurs de développement ne sont pas encore lancés. Le gestionnaire fourni implémente un état de santé public et une exécution à blanc de maintenance synthétique ; le problème se trouve dans la configuration publique de l’environnement de prévisualisation et dans le chargement de ses identifiants.
Périmètre
Travaillez avec wrangler.jsonc, src/index.js, .dev.vars.preview, .dev.vars.live et .gitignore. Inspectez le gestionnaire et la configuration pour identifier le contrat des bindings. Les deux fichiers dotenv contiennent des identifiants de test aléatoires et différents. Vous pouvez inspecter leurs noms de clés sans afficher leurs valeurs. Gardez les identifiants privés dans cette VM et excluez-les de Git.
Lancez l’environnement Wrangler preview sur le port loopback 8080 et live sur le port 8081. Attribuez des ports d’inspection différents aux deux exécutions simultanées. Utilisez les commandes ordinaires de développement de Wrangler installé localement dans le projet ; ce défi ne crée aucune ressource distante. QUEUE_LABEL est une chaîne d’affichage, pas un service de file d’attente.
Votre objectif
Les deux environnements locaux doivent exposer l’identité publique qui leur est destinée et n’autoriser la maintenance qu’avec leur propre identifiant configuré. L’environnement de prévisualisation doit être isolé de la production, et l’état de santé public ainsi que le comportement d’échec sécurisé existants doivent rester disponibles.
Critères d’acceptation
- GET
/healthrenvoie du JSON avec le statutok. La prévisualisation identifie l’environnementpreviewet la filesandbox; la production identifie l’environnementliveet la fileprimary. - Chaque environnement charge son propre identifiant synthétique via le binding
MAINTENANCE_TOKENdu gestionnaire. Les deux valeurs d’identifiant doivent rester distinctes, en dehors du code source et des variables publiques de Wrangler. Les fichiers dotenv locaux restent lisibles uniquement par l’utilisateur de la VM et sont exclus de Git. - POST
/maintenancerenvoie 200 avecoperation: dry-runet le nom de l’environnement uniquement lorsque la requête contient un identifiant Bearer valide pour cet environnement. Les identifiants absents, invalides ou provenant de l’autre environnement renvoient 401 avecerror: unauthorized. - Lorsqu’un secret configuré est absent, l’échec doit être sécurisé : le service renvoie 503 avec
error: maintenance_unconfigured. GET/maintenancereste en 405 avecerror: method_not_allowed; une route inconnue reste en 404 avecerror: not_found. - Les réponses et les journaux de l’application ne contiennent aucune valeur d’identifiant. Les deux serveurs locaux restent actifs pour les deux vérifications de cette étape. Aucune autorisation cloud, aucun déploiement, aucun rapport ni marqueur de réussite copié n’est requis.
Indications
Comparer la source de chaque valeur publique
Lisez les recherches d’environnement dans le gestionnaire, puis comparez-les aux objets d’environnement nommés dans wrangler.jsonc. Les variables d’environnement Wrangler ne sont pas héritées automatiquement. L’environnement sélectionné par une exécution et les valeurs contenues dans cet environnement sont deux éléments distincts.
Analyser une réponse maintenance_unconfigured
Faites la distinction entre un binding configuré manquant et un identifiant entrant refusé. Comparez le nom du binding utilisé par le gestionnaire avec les noms de clés du fichier dotenv propre à l’environnement. L’existence d’un fichier local ne garantit pas qu’il définit le binding lu par le gestionnaire. Après toute modification de configuration, vérifiez à nouveau que l’exécution est prête.
Préserver le comportement de la production et la limite de sécurité
Testez l’état de santé et la maintenance dans les deux sens. Un identifiant valide dans un environnement doit être invalide dans l’autre. L’opération de maintenance fournie est une exécution à blanc ; une requête correctement autorisée ne modifie donc aucune donnée de l’application.
Laisser un espace de travail propre
Situation actuelle
Les environnements locaux corrigés ont réussi les vérifications fonctionnelles. Leurs processus de développement et leurs fichiers d’identifiants synthétiques sont encore présents dans cette VM.
Périmètre
Seuls les processus de développement de ce défi sur les ports 8080 et 8081, ses fichiers .dev.vars.preview et .dev.vars.live, ainsi que les variables du shell contenant leurs valeurs sont temporaires. Préservez le code source corrigé, la configuration, les dépendances et les services LabEx.
Votre objectif
Le projet corrigé reste disponible, sans serveur du défi en cours d’exécution ni fichier de secret local restant.
Critères d’acceptation
- Aucun serveur de développement n’écoute sur le port 8080 ou 8081.
- Aucun fichier de secret
.dev.vars*ou.env*ne reste dans le projet du défi. - Effacez les variables du shell utilisées pour les identifiants synthétiques. Il s’agit d’une action de nettoyage côté apprenant ; le backend ne peut pas inspecter l’état de votre shell interactif.
- Préservez les processus et fichiers sans rapport avec ce défi. Aucune ressource cloud ni aucun identifiant Cloudflare ne doit être supprimé dans ce défi local uniquement.
Indications
Cibler les tâches que vous avez lancées
Utilisez la liste des tâches de votre shell pour identifier les deux processus de développement Wrangler. Les numéros de tâches peuvent changer après le redémarrage d’un serveur. Effectuez les vérifications fonctionnelles avant le nettoyage ; supprimer les secrets en premier rendrait les vérifications précédentes non concluantes.
Résumé
Vous avez relié le décalage d’identité de preview aux valeurs de l’environnement nommé et l’échec de maintenance au nom du binding d’identifiant. La correction a rétabli l’isolation de preview tout en conservant le comportement de live, l’état de santé public et l’autorisation côté serveur.
Les tests avec des identifiants absents, invalides, provenant de l’autre environnement et valides ont établi la limite de sécurité plus complètement qu’une seule réponse positive. Le nettoyage final a supprimé les processus locaux et les secrets synthétiques tout en conservant le projet corrigé.

