Konfigurationsabweichungen in der Vorschau beheben

Einführung

Die Vorschau-API eines Supportteams meldet die Konfiguration der Live-Umgebung, und der Wartungs-Trockenlauf weist das Vorschau-Zugangstoken zurück. Die Live-Umgebung funktioniert weiterhin. Ihre Aufgabe besteht darin, die Grenze der Vorschau wiederherzustellen, ohne die Autorisierung für Wartungsarbeiten zu schwächen oder das Verhalten der Live-Umgebung zu ändern.

Diese unabhängige Aufgabe stellt in einer neuen VM einen kleinen Worker, zwei benannte lokale Umgebungen und synthetische Zugangsdaten bereit. Wenden Sie die Vorgehensweisen zur Konfiguration, zum Laden von Secrets und zum Testen der Laufzeit aus den geführten Labs an. Die Aufgabe ist erfolgreich, wenn beide lokalen Umgebungen den folgenden Anforderungen entsprechen. Entfernen Sie anschließend die temporären Server und Secret-Dateien. Die Namen preview und live bezeichnen hier lokale Testumgebungen. Für diese Aufgabe sind weder eine Cloudflare-Anmeldung noch ein Deployment erforderlich.

Isolation der Vorschau wiederherstellen

Aktuelle Situation

Das vorbereitete Projekt befindet sich unter /home/labex/project/preview-drift. Node 22.22.0, das lokale Wrangler-Projektpaket 4.131.1 und die unabhängige Testlaufzeit sind installiert. Entwicklungsserver laufen noch nicht. Der bereitgestellte Handler implementiert einen öffentlichen Health-Check und einen synthetischen Wartungs-Trockenlauf. Der Fehler liegt in der öffentlichen Konfiguration der Vorschauumgebung und beim Laden der Zugangsdaten.

Umfang

Arbeiten Sie mit wrangler.jsonc, src/index.js, .dev.vars.preview, .dev.vars.live und .gitignore. Untersuchen Sie Handler und Konfiguration, um den Binding-Vertrag zu finden. Die beiden dotenv-Dateien enthalten unterschiedliche zufällige Testzugangsdaten. Sie dürfen ihre Schlüsselnamen anzeigen, aber nicht ihre Werte. Halten Sie die Zugangsdaten innerhalb dieser VM geheim und schließen Sie sie von Git aus.

Starten Sie die Wrangler-Umgebung preview auf dem Loopback-Port 8080 und live auf Port 8081. Verwenden Sie für gleichzeitig laufende Runtimes unterschiedliche Inspector-Ports. Nutzen Sie die normalen lokalen Wrangler-Entwicklungsbefehle des Projekts. Diese Aufgabe erstellt keine entfernten Ressourcen. QUEUE_LABEL ist eine Anzeigekennung und kein Queue-Dienst.

Ihr Ziel

Beide lokalen Umgebungen müssen ihre vorgesehene öffentliche Identität bereitstellen und Wartungszugriffe nur mit der jeweils eigenen konfigurierten Zugangsdaten erlauben. Die Vorschau muss von der Live-Umgebung isoliert sein. Der vorhandene öffentliche Health-Check und das sichere Fehlerverhalten müssen erhalten bleiben.

Abnahmekriterien

• GET /health gibt JSON mit dem Status ok zurück. Die Vorschau muss die Umgebung preview und die Queue sandbox melden. Die Live-Umgebung muss die Umgebung live und die Queue primary melden.
• Jede Umgebung lädt ihre eigene synthetische Zugangsdaten über das Binding MAINTENANCE_TOKEN des Handlers. Die beiden Werte müssen unterschiedlich bleiben und außerhalb des Quellcodes sowie der öffentlichen Wrangler-Variablen gespeichert werden. Die lokalen dotenv-Dateien dürfen nur für den VM-Benutzer lesbar und müssen von Git ausgeschlossen sein.
• POST /maintenance gibt nur dann 200 mit operation: dry-run und dem Namen der Umgebung zurück, wenn das gültige Bearer-Zugangstoken dieser Umgebung verwendet wird. Fehlende, ungültige Zugangsdaten und Zugangsdaten der jeweils anderen Umgebung müssen 401 mit error: unauthorized zurückgeben.
• Ein fehlendes konfiguriertes Secret muss mit 503 und error: maintenance_unconfigured sicher fehlschlagen. GET /maintenance bleibt 405 mit error: method_not_allowed; eine unbekannte Route bleibt 404 mit error: not_found.
• Antworten und Anwendungsprotokolle dürfen keine Zugangsdaten enthalten. Beide lokalen Server müssen für die beiden Prüfungen dieses Schritts weiterlaufen. Eine Cloud-Autorisierung, ein Deployment, ein Bericht oder eine kopierte Erfolgsmarkierung ist nicht erforderlich.

Hinweise

Einen sauberen Arbeitsbereich hinterlassen

Aktuelle Situation

Die reparierten lokalen Umgebungen haben die Funktionstests bestanden. Ihre Entwicklungsprozesse und synthetischen Secret-Dateien sind in dieser VM noch vorhanden.

Umfang

Nur die Entwicklungsjobs dieser Aufgabe auf den Ports 8080 und 8081, die Dateien .dev.vars.preview und .dev.vars.live sowie die Shell-Variablen mit ihren Werten sind temporär. Bewahren Sie den reparierten Quellcode, die Konfiguration, die Abhängigkeiten und die LabEx-Dienste auf.

Ihr Ziel

Das reparierte Projekt bleibt verfügbar, ohne laufenden Aufgabenserver und ohne zurückbleibende lokale Secret-Dateien.

Abnahmekriterien

• Auf Port 8080 und Port 8081 darf kein Entwicklungsserver lauschen.
• Im Projekt dieser Aufgabe darf keine Secret-Datei .dev.vars* oder .env* verbleiben.
• Löschen Sie die für die synthetischen Zugangsdaten verwendeten Shell-Variablen. Dies ist eine Bereinigungsaktion auf Lernendenseite; das Backend kann den Zustand Ihrer interaktiven Shell nicht prüfen.
• Bewahren Sie nicht zusammenhängende Prozesse und Dateien auf. In dieser rein lokalen Aufgabe gibt es keine Cloud-Ressourcen oder Cloudflare-Zugangsdaten, die entfernt werden müssten.

Hinweise

Zusammenfassung

Sie haben die Abweichung bei der Identität der Vorschau auf die Werte der benannten Umgebungen zurückgeführt und den Wartungsfehler durch den Namen des Zugangsdaten-Bindings erklärt. Die Reparatur stellt die Isolation der Vorschau wieder her und erhält gleichzeitig das Live-Verhalten, den öffentlichen Health-Check und die serverseitige Autorisierung.

Durch das Testen fehlender, ungültiger, umgebungsübergreifender und gültiger Zugangsdaten wurde die Grenze gründlicher geprüft als mit einer einzelnen erfolgreichen Antwort. Die abschließende Bereinigung entfernte die lokalen Prozesse und synthetischen Secrets, während das reparierte Projekt erhalten blieb.