suya auth

suya auth gère la manière dont la CLI s’authentifie contre l’API Subaya. Pour l’aperçu conceptuel des deux modes d’identification, consultez Authentification & clés API.

`suya auth login`

Connectez-vous de manière interactive avec le flux OAuth dans le navigateur.

suya auth login
suya auth login --no-browser

Drapeau	Description
`--no-browser`	Ne pas lancer de navigateur. Afficher un code court à approuver depuis n’importe quel appareil (le flux d’appareil, ci-dessous).

Par défaut, la CLI ouvre un navigateur via une redirection en boucle locale et stocke localement le jeton résultant. C’est le chemin le plus rapide lorsque le navigateur se trouve sur la même machine que la CLI — la cible de la redirection est 127.0.0.1, donc il le faut.

Si le navigateur ne peut pas être ouvert, ou si la redirection ne revient jamais (le signe habituel que votre navigateur est ailleurs — SSH, un conteneur, une machine de développement distante), la CLI bascule automatiquement vers le flux d’appareil. Vous n’avez rien à relancer.

Pour les agents et la CI, préférez définir SUBAYA_API_KEY plutôt que de vous connecter — aucun navigateur n’est impliqué.

Se connecter sans navigateur (flux d’appareil)

Utilisez ceci lorsque la machine qui exécute suya n’a pas de navigateur : via SSH, dans un conteneur, sur une machine de compilation distante.

suya auth login --no-browser

La CLI affiche un code et deux liens, puis attend :

  Open this link on any device:  https://subaya-dev.com/auth/device?user_code=KHTM-BQWD
  Or go to https://subaya-dev.com/auth/device and enter:  KHTM-BQWD

Waiting for approval... (Ctrl-C to cancel)

Ouvrez cette page sur l’appareil de votre choix disposant d’un navigateur — votre ordinateur portable, votre téléphone — connectez-vous si ce n’est pas déjà fait, vérifiez que le code affiché à l’écran correspond à celui de votre terminal, puis approuvez. La page indique la machine à l’origine de la demande, ce qui vous permet de distinguer votre propre connexion d’une connexion que vous n’avez pas lancée. La CLI s’en aperçoit en quelques secondes, enregistre le jeton et affiche le compte avec lequel elle s’est connectée.

Rien n’est jamais saisi en retour dans le terminal, ce qui permet à ce flux de fonctionner depuis un script ou un agent aussi bien que depuis un shell.

Remarques :

Le code est valable 10 minutes et ne peut être utilisé qu’une seule fois. S’il expire, relancez la commande pour en obtenir un nouveau.
L’approbation accorde à la CLI un accès en tant que vous, dans votre organisation actuellement active. Pour vous connecter contre une autre organisation, changez d’organisation dans la console au préalable, puis relancez suya auth login.
Si vous n’êtes pas à l’origine de la connexion, cliquez sur Deny — aucun jeton n’est émis.

`suya auth logout`

Se déconnecter et révoquer le jeton stocké localement.

suya auth logout

`suya auth status`

Afficher votre statut d’authentification local. Ceci n’appelle pas le serveur — il rapporte quelles identifications la CLI possède sur disque.

suya auth status

`suya auth whoami`

Appeler le serveur (/api/auth/cli/whoami) et afficher l’identité que votre identifiant actuel résout. Cela fonctionne pour les deux types d’identifiants : un jeton issu de suya auth login, et une SUBAYA_API_KEY. Utilisez-le pour confirmer qu’une clé est correctement configurée avant de la confier à la CI.

export SUBAYA_API_KEY="sk_live_..."
suya auth whoami

Si l’identifiant est rejeté, whoami en indique la raison plutôt que d’échouer sans explication :

Raison	Signification
`unknown_key`	La clé d’API n’est pas reconnue — révoquée, expirée, ou n’ayant jamais existé. Émettez-en une nouvelle dans la console sous Settings → API keys.
`wrong_environment`	La clé est bien formée mais appartient à l’autre environnement (voir ci-dessous). Le message indique où émettre la bonne.
`unknown_token`	Votre jeton de connexion a expiré ou a été révoqué. Relancez `suya auth login`.
`no_credential`	Aucun identifiant n’a été présenté. Définissez `SUBAYA_API_KEY` ou lancez `suya auth login`.

Les clés sont propres à chaque environnement

Les clés d’API portent leur environnement dans leur préfixe, et une clé n’est valable que contre l’hôte pour lequel elle a été émise :

sk_live_… — l’API de production (https://subaya-dev.com), la valeur par défaut de --host.
sk_test_… — réservé aux environnements hors production.

Une clé sk_test_ envoyée à l’hôte de production est rejetée avec wrong_environment, et non avec un générique « clé invalide » — donc si vous voyez cela, la solution est d’émettre une clé du bon type, et non de partir à la recherche d’une clé révoquée. Émettez les clés depuis la console sous Settings → API keys, sur l’environnement que vous comptez appeler.

Voir aussi

Démarrage rapide — se connecter et lancer votre première simulation.
Aperçu de la CLI — drapeaux globaux et la surface de commandes complète.