Testbenutzer mit keenauth test login anmelden

keenauth test login meldet einen Testbenutzer in einer development-Umgebung an und gibt die Tokens aus, damit Sie Ihre API aufrufen oder Ihr Backend testen können, ohne sich über die Anmeldeseite durchklicken zu müssen. Der Befehl verwendet die echte gehostete Anmeldung, so wie ein Browser es tut, und den festen Entwicklungscode 424242 (siehe Testbenutzer und Nachrichten in Nicht-Produktionsumgebungen).

Der Befehl benötigt weder einen API-Schlüssel noch eine keenauth login-Sitzung: Er meldet den Testbenutzer an, nicht Sie.

Bevor Sie beginnen

• Ein Testbenutzer. Die Adresse muss im lokalen Teil das Tag +test enthalten, zum Beispiel ada+test@example.com oder ada+test_1@example.com. Legen Sie den Benutzer zuerst an, zum Beispiel mit keenauth users create --email ada+test@example.com. Der Befehl lehnt jede andere Adresse ab, bevor er eine Anfrage sendet, und wird mit dem Code 2 beendet.
• Eine öffentliche Anwendung. Übergeben Sie mit --client-id die ID einer nativen oder Single-Page-Anwendung der Umgebung. Die Anwendung muss die Anmeldung mit einem E-Mail-Code (passwortlos, email_otp) erlauben.
• Eine Weiterleitungs-URI. Standardmäßig verwendet der Befehl http://127.0.0.1:<zufälliger Port>/callback. Registrieren Sie http://127.0.0.1/callback für die Anwendung: Eine Loopback-Weiterleitungs-URI akzeptiert jeden Port (RFC 8252). An dieser Adresse lauscht nichts; der Befehl liest die Weiterleitung selbst. Um eine andere registrierte Weiterleitungs-URI zu verwenden, übergeben Sie --redirect-uri.
• Der Issuer der Umgebung. Übergeben Sie ihn mit --issuer oder setzen Sie KEENAUTH_ISSUER, zum Beispiel https://acme-dev.keenauth.app.

Verwendung

export KEENAUTH_ISSUER=https://acme-dev.keenauth.app
keenauth test login --user ada+test@example.com --client-id app_01j9z3k4m5n6p7q8r9s0t1v2w3

Die Ausgabe enthält token_type, access_token, id_token (wenn openid angefordert wird), refresh_token (nur wenn offline_access angefordert wird), expires_in und scope. Behandeln Sie die Tokens wie Passwörter: Solange sie gültig sind, handeln sie als Testbenutzer. Der Befehl schreibt sie nur auf die Standardausgabe und sonst nirgendwohin, und er gibt den Code niemals aus.

ACCESS_TOKEN=$(keenauth test login --user ada+test@example.com --client-id app_01j9z3k4m5n6p7q8r9s0t1v2w3 -o json | jq -r .access_token)
curl -H "Authorization: Bearer $ACCESS_TOKEN" http://localhost:3000/api/orders

Was der Befehl tut

1. Liest das Discovery-Dokument der Umgebung und öffnet eine Autorisierungsanfrage mit PKCE (S256), state und nonce.
2. Auf der gehosteten Anmeldeseite gibt er die Adresse ein, fordert einen E-Mail-Code an und sendet 424242. Verlangt die Umgebung danach einen E-Mail-Code als zweiten Faktor, fordert er diesen Code an und sendet erneut 424242.
3. Folgt der Weiterleitung zurück zur Weiterleitungs-URI, prüft state und iss und tauscht den Autorisierungscode am Token-Endpunkt gegen Tokens.
4. Prüft, dass das ID-Token vom Issuer für Ihre Anwendung mit dem nonce der Anfrage ausgestellt wurde, und gibt die Tokens aus.

Der Befehl bricht mit einem Fehler ab, wenn die Anmeldung etwas anderes erfordert, zum Beispiel ein Passwort, einen Passkey, eine Authentifizierungs-App, Enterprise Single Sign-On für die Domain der Adresse, eine Zustimmungsseite oder die Auswahl einer Organisation.

Umgebungen

Nur development-Umgebungen akzeptieren den festen Code. Verwenden Sie den Befehl nur mit einer Entwicklungsumgebung:

• In staging wird nichts an Testadressen gesendet, der feste Code wird jedoch abgelehnt (401 invalid_credentials).
• In production ist eine +test-Adresse eine gewöhnliche Adresse: Der E-Mail-Code wird tatsächlich an sie gesendet, und der feste Code wird abgelehnt.

Wenn der Server einen Schritt ablehnt, gibt die CLI seine Problemantwort unverändert aus (error, code, status, detail, request_id), zum Beispiel code: test_feature_not_in_production.

Exit-Codes