Konfiguration
Umgebungsvariablen
Verwendung
Logto verarbeitet Umgebungsvariablen in folgender Reihenfolge:
- System-Umgebungsvariablen
- Die
.env-Datei im Projektstamm, die dem dotenv-Format entspricht
Daher überschreiben die System-Umgebungsvariablen die Werte in .env.
Variablen
Wenn du Logto über npm start im Projektstamm ausführst, ist NODE_ENV immer production.
Bei Standardwerten ist protocol entweder http oder https entsprechend deiner HTTPS-Konfiguration.
| Key | Standardwert | Typ | Beschreibung |
|---|---|---|---|
| NODE_ENV | undefined | 'production' | 'test' | undefined | In welcher Art von Umgebung Logto ausgeführt wird. |
| PORT | 3001 | number | Der lokale Port, auf dem Logto lauscht. |
| ADMIN_PORT | 3002 | number | Der lokale Port, auf dem die Logto Admin Console lauscht. |
| ADMIN_DISABLE_LOCALHOST | N/A | string | boolean | number | Setze es auf 1 oder true, um den Port für die Admin Console zu deaktivieren. Wenn ADMIN_ENDPOINT nicht gesetzt ist, wird die Admin Console vollständig deaktiviert. |
| DB_URL | N/A | string | Die Postgres DSN für die Logto-Datenbank. |
| DATABASE_STATEMENT_TIMEOUT | N/A | string | (v1.36.0+) PostgreSQL statement_timeout in Millisekunden. Verwende einen numerischen String (z. B. 5000), um ihn zu setzen, oder DISABLE_TIMEOUT, um den Startparameter zu überspringen (empfohlen für PgBouncer/RDS Proxy). Wenn nicht gesetzt oder ungültig, ist der Standardwert 60000 ms. |
| HTTPS_CERT_PATH | undefined | string | undefined | Siehe HTTPS aktivieren für Details. |
| HTTPS_KEY_PATH | undefined | string | undefined | Siehe oben. |
| TRUST_PROXY_HEADER | false | boolean | Siehe oben. |
| ENDPOINT | 'protocol://localhost:$PORT' | string | Du kannst eine URL mit deiner eigenen Domain für Online-Tests oder Produktion angeben. Dies beeinflusst auch den Wert des OIDC-Aussteller-Identifiers. |
| ADMIN_ENDPOINT | 'protocol://localhost:$ADMIN_PORT' | string | Du kannst eine URL mit deiner eigenen Domain für die Produktion angeben (z. B. ADMIN_ENDPOINT=https://admin.domain.com). Dies beeinflusst auch die Redirect-URIs der Admin Console. |
| CASE_SENSITIVE_USERNAME | true | boolean | Gibt an, ob der Benutzername Groß- / Kleinschreibung beachtet. Sei vorsichtig beim Ändern dieses Wertes; Änderungen passen bestehende Daten in der Datenbank nicht automatisch an und erfordern manuelle Verwaltung. |
| SECRET_VAULT_KEK | undefined | string | Der Key Encryption Key (KEK), der zum Verschlüsseln von Data Encryption Keys (DEK) im Secret Vault verwendet wird. Erforderlich, damit der Secret Vault ordnungsgemäß funktioniert. Muss ein base64-codierter String sein. AES-256 (32 Bytes) wird empfohlen. Beispiel: crypto.randomBytes(32).toString('base64') |
| PRIVATE_KEY_ROTATION_GRACE_PERIOD | 0 | number | Schonfrist in Sekunden für gestaffelte OIDC-Private-Key-Rotation. Bei einem positiven Wert wird der neue Private Key zuerst als Next erstellt und wird erst nach Ablauf der Schonfrist wirksam. |
| OIDC_PROVIDER_SSRF_PROTECTION_DISABLED | false | boolean | Nur für Self-Hosting. Setze auf true nur, wenn vertrauenswürdige OIDC-Relying-Party-Endpunkte auf private Netzwerkadressen aufgelöst werden müssen. Siehe OIDC-Provider SSRF-Schutz. |
OIDC-Provider SSRF-Schutz
Logto schützt die ausgehenden Anfragen des OIDC-Providers standardmäßig vor Server-Side Request Forgery (SSRF). Anfragen an spezielle Adressen, einschließlich Loopback- und privaten Netzwerkadressen, werden blockiert. Dieser Schutz umfasst Relying-Party-Endpunkte wie Back-Channel-Logout-URIs, jwks_uri und sector_identifier_uri.
Wenn deine selbst gehostete Bereitstellung absichtlich einen vertrauenswürdigen Relying-Party-Endpunkt in einem privaten Netzwerk erreichen muss, setze OIDC_PROVIDER_SSRF_PROTECTION_DISABLED=true und starte jede Logto-Instanz neu.
Diese Einstellung deaktiviert den SSRF-Schutz für alle ausgehenden OIDC-Provider-Anfragen, nicht nur für einen Endpunkt. Deaktiviere sie nur, wenn alle konfigurierten Relying-Party-Endpunkte vertrauenswürdig sind und deine Netzwerkkontrollen den Zugriff auf sensible interne Dienste verhindern.
HTTPS aktivieren
Verwendung von Node
Node unterstützt HTTPS nativ. Gib SOWOHL HTTPS_CERT_PATH als auch HTTPS_KEY_PATH an, um HTTPS über Node zu aktivieren.
HTTPS_CERT_PATH gibt den Pfad zu deinem HTTPS-Zertifikat an, während HTTPS_KEY_PATH den Pfad zu deinem HTTPS-Schlüssel angibt.
Verwendung eines HTTPS-Proxys
Eine weitere gängige Praxis ist es, einen HTTPS-Proxy vor Node zu schalten (z. B. Nginx).
In diesem Fall möchtest du wahrscheinlich TRUST_PROXY_HEADER auf true setzen, was angibt, ob Proxy-Header-Felder vertraut werden sollen. Logto gibt den Wert an die Koa-App-Einstellungen weiter.
Siehe Vertrauen von TLS-Offloading-Proxies, um zu erfahren, wann dieses Feld konfiguriert werden sollte.
Datenbank-Konfigurationen
Das Verwalten zu vieler Umgebungsvariablen ist weder effizient noch flexibel, daher werden die meisten allgemeinen Konfigurationen in der Datenbanktabelle logto_configs gespeichert.
Die Tabelle ist ein einfacher Key-Value-Speicher, und der Schlüssel ist wie folgt aufzählbar:
| Key | Typ | Beschreibung |
|---|---|---|
| oidc.cookieKeys | string[] | Das String-Array der Signatur-Cookie-Keys. |
| oidc.privateKeys | string[] | Das String-Array des Private-Key-Inhalts für OIDC JWT-Signierung. |
Unterstützte Private-Key-Typen
- EC (P-256, secp256k1, P-384 und P-521 Kurven)
- RSA
- OKP (Ed25519, Ed448, X25519, X448 Subtypen)