Authentification de la CLI — Altifigence Documentation

Connectez-vous avec le PKCE natif de Cloud et distinguez sa session des anciens identifiants API et de service DDS.

Présentation

Choisissez le parcours d’identifiants adapté à votre commande. La connexion Cloud native, les identifiants d’actions client héritées et le service HTTP DDS configuré par un opérateur relèvent de contrats distincts. Les opérations XLS locales et d’espace de travail natives ne nécessitent pas d’identifiants Cloud.

Les identifiants desktop et CLI sont distincts

Surface	Parcours d’identifiants	Autorité
Digital Design Studio 2.0.2 Windows	Connexion par navigateur pour les fonctions locales protégées ; la modification et l’enregistrement fonctionnent aussi sans connexion	Aucune licence d’appareil My PC. Une connexion Free permet d’utiliser les fonctions locales documentées ; Cloud et l’IA vérifient des autorisations distinctes.
`alti` `ide` `cloud`	PKCE dans le navigateur et session CLI privée	L’identité du compte et les autorisations organisation/projet sont vérifiées par le serveur
Client d’actions/tâches client	`ALTI_TOKEN` et `ALTI_ORG_ID`	L’identifiant et la portée présentés à l’API sélectionnée
`alti` `ide` `service`	Origine de service configurée et `ALTI_STUDIO_SERVICE_SECRET`	Le contrat d’autorisation existant du service hérité

Aucune session CLI n’accorde de licence desktop. N’importez pas de fichiers de session desktop, de cookies de navigateur ou d’en-têtes de service internes dans une requête Cloud native.

Connexion Cloud native

alti ide cloud login
alti ide cloud whoami
alti ide cloud refresh
alti ide cloud logout

Login affiche l’URL d’autorisation du parcours PKCE dans le navigateur. Il utilise par défaut https://api.altifigence.com et un répertoire de session privé à ~/.local/state/altifigence/cloud-cli. Utilisez --session-dir de façon cohérente pour sélectionner une autre session. Login accepte également --org et un --wait-seconds borné ; les commandes suivantes utilisent leurs propres délais de requête.

Utilisez whoami pour l’identité serveur plutôt que de la déduire d’un jeton enregistré. Refresh et logout agissent sur cette session native. Les identifiants d’organisation/projet des commandes de recherche et de terminal Cloud délimitent la requête, mais ne peuvent pas accorder d’accès. Les opérations typées ide cloud run conservent les contrôles d’autorisation serveur et exigent --allow-source-upload lorsque leur contrat comporte des sources envoyées.

Le CLI se connecte via ses routes API natives explicites. Un parcours de connexion ne promet pas que toutes les opérations Cloud sont activées pour chaque organisation.

Variables d’environnement lues par le CLI

Les clients d’actions client héritées et de tâches Cloud conservent ces paramètres :

Variable	Effet
`ALTI_TOKEN`	Identifiant bearer requis ; une valeur absente ou vide est refusée
`ALTI_ORG_ID`	Portée d’organisation requise
`ALTI_API_BASE`	Base API, par défaut `https://api.altifigence.com`
`ALTI_BYO`	`1`, `true`, ou `yes` sélectionne le type de principal fourni par l’utilisateur
`ALTI_ALLOW_SOURCE_UPLOAD`	Autorisation d’envoi pour les actions MCP client contenant des sources ; l’absence vaut refus

Ne définissez une origine de remplacement que pour un service que vous contrôlez ou un endpoint explicitement fourni pour votre compte. Une origine modifiée peut envoyer l’identifiant correspondant à un autre hôte.

Les commandes HTTP DDS héritées utilisent plutôt --endpoint ou ALTI_STUDIO_ENDPOINT et la variable d’environnement existante du secret de service. Elles ne réutilisent pas la connexion Cloud native et n’inventent pas de parcours d’authentification pour ce service.

L’état de configuration n’est pas une authentification

alti auth status inspecte uniquement la configuration de l’environnement hérité. Son serverVerification reste not_performed ; ce n’est pas l’équivalent de alti ide cloud whoami.

Les commandes de premier niveau héritées alti login et alti whoami se terminent toujours avec le code 4 avec AUTH_FLOW_UNAVAILABLE et IDENTITY_NOT_VERIFIED. La commande de premier niveau alti logout ne peut pas effacer les valeurs héritées d’un processus parent. Effacez ou renouvelez ces valeurs à leur source ; utilisez ide cloud logout pour la session native.

Gestion des secrets

Conservez les identifiants CI dans le magasin de secrets CI et injectez-les uniquement dans l’étape qui en a besoin.
Gardez les répertoires de session privés à leur propriétaire ; ne les ajoutez pas au contrôle de sources, aux caches partagés entre utilisateurs ou aux artefacts publiés.
Ne journalisez ni jetons, ni secrets de service, ni cookies de navigateur, ni environnements complets.
Désactivez le traçage shell autour des commandes authentifiées et renouvelez toute valeur susceptible d’avoir été inscrite dans un journal.

Accès API distant

Utilisez les Commandes de tâches et de Cloud typées pour le backend sélectionné. La validation client et une connexion réussie ne remplacent pas les autorisations serveur et ne prouvent pas qu’une tâche demandée est achevée.

Vérifier et récupérer la session native

alti ide cloud login
alti ide cloud whoami

Exécutez ces commandes avec le même utilisateur Linux ordinaire qui utilisera le CLI. Terminez le parcours navigateur et exigez une réponse réussie de whoami avant les opérations d’espace de travail. Si vous utilisez un autre --session-dir, utilisez-le pour la connexion et les appels suivants ; un autre répertoire correspond à une autre session enregistrée.

Si la session expire, utilisez le parcours natif de renouvellement/connexion. Si l’identité est validée mais qu’un projet est refusé, examinez l’appartenance à l’organisation et les autorisations du projet. Ne copiez pas d’identifiants depuis Desktop et ne modifiez pas les origines API pour contourner ce refus. Pour récupérer un compte, utilisez Sécurité du compte.