Autenticazione CLI
Accedere con PKCE Cloud nativo e distinguere la sua sessione dalle credenziali dell'API legacy e del servizio DDS.
Overview
Scegliere il percorso delle credenziali per il comando usato. Accesso Cloud nativo, credenziali delle azioni cliente legacy e servizio HTTP DDS configurato da un operatore sono contratti distinti. XLS locale e operazioni native dell'area di lavoro non richiedono credenziali Cloud.
Le credenziali desktop e CLI sono separate
Interfaccia | Percorso delle credenziali | Autorità |
|---|---|---|
Digital Design Studio 2.0.2 Windows | Accesso nel browser per le funzionalità locali protette; modifica e salvataggio funzionano anche senza accedere | Nessuna licenza del dispositivo My PC. L'accesso Free supporta le funzionalità locali documentate; Cloud e AI verificano autorizzazioni separate. |
| PKCE nel browser e sessione CLI privata | Identità dell'account e autorizzazioni dell'organizzazione/progetto sono controllate dal server |
Client delle azioni/job cliente |
| Le credenziali e l'ambito presentati all'API selezionata |
| Origine del servizio configurata e | Il contratto di autorizzazione esistente del servizio legacy |
Nessuna sessione CLI concede una licenza desktop. Non importare file di sessione desktop, cookie del browser né header interni di servizio in una richiesta Cloud nativa.
Accesso Cloud nativo
alti ide cloud login
alti ide cloud whoami
alti ide cloud refresh
alti ide cloud logout
Login stampa l'URL di autorizzazione per il flusso PKCE del browser. Usa per impostazione predefinita https://api.altifigence.com e una directory privata di sessione in ~/.local/state/altifigence/cloud-cli. Usare --session-dir in modo coerente per selezionare un'altra sessione. Login accetta anche --org e un --wait-seconds limitato; i comandi successivi usano le proprie scadenze di richiesta.
Usare whoami per l'identità server anziché dedurla da un token archiviato. Refresh e logout operano su questa sessione nativa. Gli ID di organizzazione/progetto nei comandi Cloud di ricerca e terminale definiscono l'ambito della richiesta ma non possono concedere accesso. Le operazioni tipizzate ide cloud run mantengono i controlli di autorizzazione server e richiedono --allow-source-upload quando il loro contratto contiene sorgenti caricati.
La CLI si collega tramite le proprie route API native esplicite. Un flusso di accesso non garantisce che ogni operazione Cloud sia abilitata per ogni organizzazione.
Variabili di ambiente lette dalla CLI
I client legacy di azioni cliente e job Cloud mantengono queste impostazioni:
Variabile | Effetto |
|---|---|
| Credenziale bearer obbligatoria; un valore assente o vuoto viene rifiutato |
| Ambito organizzativo obbligatorio |
| Base API, predefinita |
|
|
| Consenso per le azioni MCP cliente che contengono sorgenti; l'assenza significa rifiuto |
Impostare override degli endpoint soltanto su servizi sotto il proprio controllo o endpoint forniti esplicitamente per il proprio account. Una diversa origine può inviare la credenziale corrispondente a un altro host.
I comandi HTTP DDS legacy usano invece --endpoint oppure ALTI_STUDIO_ENDPOINT e l'impostazione di ambiente esistente del segreto del servizio. Non riutilizzano l'accesso Cloud nativo né inventano un flusso di autenticazione per quel servizio.
Lo stato di configurazione non è autenticazione
alti auth status esamina soltanto la configurazione legacy di ambiente. Il suo serverVerification rimane not_performed; non è l'equivalente di alti ide cloud whoami.
I comandi legacy di livello principale alti login e alti whoami terminano ancora con 4 con AUTH_FLOW_UNAVAILABLE e IDENTITY_NOT_VERIFIED. Il comando di livello principale alti logout non può cancellare valori ereditati da un processo padre. Cancellare o ruotare tali valori alla fonte; usare ide cloud logout per la sessione nativa.
Gestione dei segreti
Conservare le credenziali CI nell'archivio dei segreti CI e inserirle soltanto nel passaggio che ne ha bisogno.
Mantenere private le directory di sessione per il loro proprietario; non aggiungerle al controllo versione, a cache condivise tra utenti né ad artefatti pubblicati.
Non registrare nei log token, segreti di servizio, cookie del browser né ambienti completi.
Disabilitare il tracciamento della shell attorno ai comandi con credenziali e ruotare ogni valore che potrebbe essere finito in un log.
Accesso API remoto
Usare i comandi tipizzati Job e Cloud per il backend selezionato. Validazione client e accesso riuscito non sostituiscono le autorizzazioni lato server né dimostrano che un job richiesto sia stato completato.
Verificare e recuperare la sessione nativa
alti ide cloud login
alti ide cloud whoami
Eseguirli come lo stesso utente Linux normale che userà la CLI. Completare il flusso nel browser e richiedere una risposta riuscita di whoami prima delle operazioni sull'area di lavoro. Se si usa un --session-dir alternativo, usarlo per login e chiamate successive; una directory diversa è una sessione salvata diversa.
Se la sessione scade, usare il flusso nativo di aggiornamento/accesso. Se la verifica dell'identità riesce ma il progetto viene negato, esaminare appartenenza all'organizzazione e autorizzazioni del progetto. Non copiare credenziali dal desktop né cambiare le origini API per aggirare il rifiuto. Per il recupero dell'account, usare Sicurezza dell'account.