Connecter des utilisateurs de test avec keenauth test login

keenauth test login connecte un utilisateur de test à un environnement development et affiche les jetons, afin que vous puissiez appeler votre API ou tester votre backend sans passer par la page de connexion. Elle passe par la véritable connexion hébergée, de la même manière qu'un navigateur, et utilise le code fixe de développement 424242 (voir Utilisateurs et messages de test dans les environnements hors production).

La commande n'exige ni clé d'API ni session keenauth login : c'est l'utilisateur de test qui se connecte, et non vous.

Avant de commencer

• Un utilisateur de test. L'adresse doit contenir le marqueur +test dans sa partie locale, par exemple ada+test@example.com ou ada+test_1@example.com. Créez d'abord l'utilisateur, par exemple avec keenauth users create --email ada+test@example.com. La commande refuse toute autre adresse avant d'envoyer une requête et se termine avec le code 2.
• Une application publique. Indiquez l'identifiant d'une application native ou monopage de l'environnement avec --client-id. L'application doit autoriser la connexion par code envoyé par e-mail (sans mot de passe, email_otp).
• Une URI de redirection. Par défaut, la commande utilise http://127.0.0.1:<port aléatoire>/callback. Enregistrez http://127.0.0.1/callback pour l'application : une URI de redirection de boucle locale accepte n'importe quel port (RFC 8252). Rien n'écoute à cette adresse ; la commande lit elle-même la redirection. Pour utiliser une autre URI de redirection enregistrée, passez --redirect-uri.
• L'émetteur de l'environnement. Indiquez-le avec --issuer ou définissez KEENAUTH_ISSUER, par exemple https://acme-dev.keenauth.app.

Utilisation

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

La sortie contient token_type, access_token, id_token (lorsque openid est demandé), refresh_token (uniquement lorsque offline_access est demandé), expires_in et scope. Traitez les jetons comme des mots de passe : ils agissent en tant qu'utilisateur de test jusqu'à leur expiration. La commande les écrit sur la sortie standard et nulle part ailleurs, et n'affiche jamais le code.

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

Ce que fait la commande

1. Lit le document de découverte de l'environnement et ouvre une requête d'autorisation avec PKCE (S256), state et nonce.
2. Sur la page de connexion hébergée, saisit l'adresse, demande un code par e-mail et soumet 424242. Si l'environnement demande ensuite un code par e-mail comme second facteur, la commande demande ce code et soumet à nouveau 424242.
3. Suit la redirection vers l'URI de redirection, vérifie state et iss, puis échange le code d'autorisation au point de terminaison des jetons.
4. Vérifie que le jeton d'identité a été émis par l'émetteur pour votre application avec le nonce de la requête, puis affiche les jetons.

La commande s'arrête avec une erreur lorsque la connexion exige autre chose, par exemple un mot de passe, une clé d'accès, une application d'authentification, une authentification unique d'entreprise pour le domaine de l'adresse, une page de consentement ou un choix d'organisation.

Environnements

Seuls les environnements development acceptent le code fixe. N'utilisez la commande qu'avec un environnement de développement :

• Dans staging, rien n'est envoyé aux adresses de test, mais le code fixe est refusé (401 invalid_credentials).
• Dans production, une adresse +test est une adresse ordinaire : le code par e-mail lui est réellement envoyé, et le code fixe est refusé.

Lorsque le serveur refuse une étape, la CLI affiche sa réponse de problème telle quelle (error, code, status, detail, request_id), par exemple code: test_feature_not_in_production.

Codes de sortie