Das Passwort im Code
Mira schreibt das Passwort der Datenbank direkt in den Code. Dann lädt sie den Code in ein gemeinsames Projekt hoch.
Nun kennt jede Person mit Zugriff das Passwort, auch in alten Versionen. Das Team muss es ändern und alles neu ausliefern.
Diese Lektion zeigt, wo Einstellungen stattdessen stehen.
Am Ende dieser Lektion
Notiz
Ich kann Einstellungen aus dem Code heraushalten.
Schlüsselwörter
| Begriff | Was er bedeutet | Beispiel |
|---|---|---|
| Konfiguration | die Einstellungen, mit denen eine App läuft | |
| Umgebungsvariable | eine Einstellung, die außerhalb des Codes gesetzt wird | DATENBANK_HOST |
| Geheimnis | ein Wert, den nicht jeder sehen darf | ein Passwort |
| Umgebung | der Ort, an dem die App läuft, etwa Test oder Live | |
| Vorgabewert | der Wert, der gilt, wenn nichts gesetzt wurde |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.
Code bleibt gleich, Einstellungen wechseln
Dieselbe App läuft an mehreren Orten: auf dem Laptop, im Test, live. Jeder Ort hat andere Werte, etwa einen anderen Datenbank-Server.
Stünden diese Werte im Code, müsste man den Code für jeden Ort ändern. Besser liest die App ihre Einstellungen von außen.
Eine Umgebungsvariable ist so eine Einstellung. Sie gehört zum Ort, nicht zum Code.
Umgebungsvariablen setzen und lesen
# Eine Einstellung steht in der Umgebung, nicht im Code
export DATENBANK_HOST="db-test.intern"
export MAX_BESTELLUNGEN="50"
echo "Die App verbindet sich mit: $DATENBANK_HOST"
echo "Höchstens $MAX_BESTELLUNGEN Bestellungen pro Stunde"
# Auf dem Live-Server stehen andere Werte. Der Code bleibt gleich.
export DATENBANK_HOST="db-live.intern"
echo "Jetzt verbindet sich die App mit: $DATENBANK_HOST"
# Setzen Sie MAX_BESTELLUNGEN auf 200 und starten Sie erneut.
Ein häufiger Fehler
Warnung
Viele denken, ein Passwort im Code sei sicher, wenn das Projekt nur im Team liegt. Das stimmt nicht. Code wird kopiert, geteilt und bleibt im Verlauf für immer sichtbar. Ein Geheimnis gehört nie in den Code. Ist es dort gelandet, ändern Sie es sofort.
Geheimnisse haben einen eigenen Ort
Lokal liegen Einstellungen oft in einer Datei namens .env. Diese Datei kommt nicht in Git: Sie steht in .gitignore.
Auf Servern kommen Geheimnisse aus einem besonderen Speicher, etwa einem Tresor des Cloud-Anbieters. Nur die App darf sie dort lesen.
Unten sehen Sie eine .env-Datei und ihre Schutzzeile.
Eine .env-Datei lesen
mkdir -p app && cd app
cat > .env <<'EOF'
DATENBANK_HOST=db-test.intern
DATENBANK_PORT=5432
PASSWORT=geheim-nur-zum-test
EOF
printf '.env\n' > .gitignore
# Die Namen der Einstellungen, ohne die Werte
cut -d= -f1 .env
# Steht .env in .gitignore? Dann nimmt Git die Datei nicht auf.
grep -x ".env" .gitignore && echo "Ja: .env wird von Git ignoriert"
# Fügen Sie eine Zeile LOG_STUFE=info zur Datei .env hinzu und starten Sie erneut.
Wohin gehört was
| Wert | Im Code | In .env oder Tresor |
|---|---|---|
| Das Passwort der Datenbank | Nein | Ja, im Tresor |
| Adresse des Test-Servers | Nein | Ja, in der Umgebung |
| Die Mehrwertsteuer-Formel | Ja | Nein |
| Ein Zugangsschlüssel zur Cloud | Nein | Ja, im Tresor |
Die Zellen, die Lernende ausfüllen, bleiben in dieser Vorschau leer.