Passwortschutz

Was geschützt wird

Der Schutz gilt je Projekt und je Umgebung:

• production: die Live-Seite mit allen Live-Adressen,
• preview: alle Previews des Projekts, auch die, die erst später entstehen.

Beide Umgebungen haben jeweils einen eigenen Benutzer mit eigenem Passwort. Du kannst nur die Previews schützen, nur die Live-Seite oder beides.

Besucher sehen das Anmeldefenster ihres Browsers (HTTP Basic Auth). Nach der Eingabe merkt sich der Browser die Anmeldung in der Regel, bis er geschlossen wird.

Schutz setzen

gooddeploy protect --env production
gooddeploy protect --env preview

gooddeploy fragt den Benutzer und zweimal das Passwort ab; die Eingabe des Passworts ist verdeckt. Regeln:

• Benutzer: 1 bis 64 Zeichen, Buchstaben, Ziffern und . _ @ -.
• Passwort: mindestens 12 Zeichen (höchstens 72 Byte), ohne Zeilenumbrüche.

Den Benutzer kannst du direkt mitgeben: gooddeploy protect --env preview --user abnahme. Setzt du den Schutz erneut, ersetzen Benutzer und Passwort die bisherigen.

Für Skripte und CI liest gooddeploy das Passwort aus der ersten Zeile der Standardeingabe:

printf '%s\n' "$PREVIEW_PASSWORD" | gooddeploy protect --env preview --user abnahme --password-stdin

--password-stdin geht nur zusammen mit --user. Schreib das Passwort nie direkt in den Befehl, sonst landet es in der Shell-Historie.

Meldet gooddeploy „laufende Instanz(en) wurden dafür neu gestartet“, hat es Versionen, die schon vor dem Schutz liefen, einmal neu gestartet, damit der Schutz auch dort greift. Das dauert wenige Sekunden.

Stand anzeigen

gooddeploy protect

zeigt für Live und Previews, ob der Schutz an ist und mit welchem Benutzer. Das Passwort zeigt gooddeploy nie an; es ist auch nirgends im Klartext gespeichert. Hast du es vergessen, setze einfach ein neues.

Schutz aufheben

gooddeploy protect off --env production
gooddeploy protect off --env preview

Auch das wirkt sofort.

Wie sich der Schutz verhält

• Wirkt sofort, ohne Deploy. Setzen und Aufheben gelten für die laufenden Versionen, du musst nichts neu bauen.
• Bleibt bei Promote und Rollback. Der Schutz hängt an der Umgebung, nicht an einem Deployment. Schaltest du eine neue Version live oder gehst zurück, ist sie genauso geschützt wie vorher.
• Liegt auf dem Server, nicht im Git. Benutzer und Passwort stehen bewusst nicht in deinem Repo und auch nicht in einer Konfigurationsdatei im Repo. Drei Gründe: Passwörter gehören nicht ins Git, wo sie in jeder Kopie und für immer in der Historie stehen. Ein Rollback auf einen alten Commit darf den Schutz nicht still aufheben. Und eine Änderung soll sofort wirken, nicht erst mit dem nächsten Deploy.
• Nicht in Suchmaschinen. Geschützte Seiten senden X-Robots-Tag: noindex, damit Suchmaschinen sie nicht aufnehmen. Previews senden diesen Hinweis immer, auch ohne Passwort.
• Gespeichert nur als Hash. gooddeploy speichert das Passwort nur in gehashter Form, nie im Klartext und nie in Protokollen.

Grenzen

• Der Passwortschutz gilt derzeit für statische Seiten (reines HTML und Builds mit Vite, Astro, React). Für Next.js-Anwendungen kommt er später; bis dahin lehnt protect sie mit einem Hinweis ab.
• Ein Freigabelink für Previews (ohne Passwort, mit Ablaufdatum) kommt später.
• Statt eines eigenen Anmeldeformulars nutzt gooddeploy das Anmeldefenster des Browsers. Das funktioniert in jedem Browser und auch mit curl -u benutzer.

Wer darf das?

Zum Setzen und Aufheben brauchst du auf dem Projekt das Recht settings (oder admin), zum Anzeigen reicht read. Siehe Rechte.