CLI-Authentifizierung — Altifigence Documentation

Melden Sie sich mit nativem Cloud-PKCE an und unterscheiden Sie diese Sitzung von älteren API- und DDS-Dienstzugangsdaten.

Überblick

Wählen Sie den Zugangsdatenpfad für den verwendeten Befehl. Native Cloud-Anmeldung, ältere Kundenaktions-Zugangsdaten und ein vom Betreiber konfigurierter DDS-HTTP-Dienst sind separate Verträge. Lokale XLS- und native Workspace-Operationen benötigen keine Cloud-Zugangsdaten.

Desktop- und CLI-Zugangsdaten sind getrennt

Oberfläche	Zugangsdatenpfad	Zuständigkeit
Digital Design Studio 2.0.2 Windows	Browseranmeldung für geschützte lokale Funktionen; Bearbeiten und Speichern funktionieren auch ohne Anmeldung	Keine Gerätelizenz für My PC. Eine Free-Anmeldung unterstützt die dokumentierten lokalen Funktionen; Cloud und KI prüfen separate Berechtigungen.
`alti` `ide` `cloud`	Browser-PKCE und eine private CLI-Sitzung	Kontoidentität sowie Organisations-/Projektberechtigungen werden vom Server geprüft
Kundenaktions-/Job-Client	`ALTI_TOKEN` und `ALTI_ORG_ID`	Die der ausgewählten API vorgelegten Zugangsdaten und der Bereich
`alti` `ide` `service`	Konfigurierte Dienst-Origin und `ALTI_STUDIO_SERVICE_SECRET`	Der bestehende Autorisierungsvertrag des Legacy-Dienstes

Keine CLI-Sitzung gewährt eine Desktop-Lizenz. Importieren Sie keine Desktop-Sitzungsdateien, Browser-Cookies oder internen Dienst-Header in eine native Cloud-Anfrage.

Native Cloud-Anmeldung

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

Login gibt die Autorisierungs-URL für den PKCE-Ablauf im Browser aus. Standardmäßig verwendet es https://api.altifigence.com und ein privates Sitzungsverzeichnis unter ~/.local/state/altifigence/cloud-cli. Verwenden Sie --session-dir durchgehend, um eine andere Sitzung zu wählen. Login akzeptiert außerdem --org und ein begrenztes --wait-seconds; nachfolgende Befehle verwenden ihre eigenen Anfragefristen.

Verwenden Sie whoami für die Serveridentität, statt sie aus einem gespeicherten Token abzuleiten. Refresh und Logout arbeiten mit dieser nativen Sitzung. Organisations-/Projekt-IDs bei Cloud-Suche und Terminalbefehlen begrenzen die Anfrage, können aber keinen Zugriff gewähren. Typisierte ide cloud run-Operationen behalten Serverberechtigungsprüfungen bei und benötigen --allow-source-upload, wenn ihr Vertrag hochgeladene Quellen enthält.

Die CLI verbindet sich über ihre expliziten nativen API-Routen. Ein Anmeldeablauf verspricht nicht, dass jede Cloud-Operation für jede Organisation freigeschaltet ist.

Von der CLI gelesene Umgebungsvariablen

Die älteren Kundenaktions- und Cloud-Job-Clients behalten folgende Einstellungen:

Variable	Wirkung
`ALTI_TOKEN`	Erforderliche Bearer-Zugangsdaten; fehlende oder leere Werte werden abgelehnt
`ALTI_ORG_ID`	Erforderlicher Organisationsbereich
`ALTI_API_BASE`	API-Basis, Standardwert `https://api.altifigence.com`
`ALTI_BYO`	`1`, `true` oder `yes` wählt die Art des selbst bereitgestellten Principals
`ALTI_ALLOW_SOURCE_UPLOAD`	Zustimmung für Kunden-MCP-Aktionen mit Quellen; fehlender Wert bedeutet Ablehnung

Setzen Sie Endpunktüberschreibungen nur auf einen Dienst, den Sie kontrollieren, oder einen ausdrücklich für Ihr Konto bereitgestellten Endpunkt. Eine geänderte Origin kann die zugehörigen Zugangsdaten an einen anderen Host senden.

Legacy-DDS-HTTP-Befehle verwenden stattdessen --endpoint oder ALTI_STUDIO_ENDPOINT sowie die bestehende Umgebungsvariable für das Dienstgeheimnis. Sie verwenden weder die native Cloud-Anmeldung erneut noch erfinden sie einen Authentifizierungsablauf für diesen Dienst.

Konfigurationsstatus ist keine Authentifizierung

alti auth status prüft nur die ältere Umgebungskonfiguration. Sein serverVerification bleibt not_performed; es entspricht nicht alti ide cloud whoami.

Die älteren Befehle auf oberster Ebene alti login und alti whoami enden weiterhin mit 4 und AUTH_FLOW_UNAVAILABLE und IDENTITY_NOT_VERIFIED. Das oberste alti logout kann keine von einem übergeordneten Prozess geerbten Werte löschen. Löschen oder rotieren Sie diese Werte an ihrer Quelle; verwenden Sie ide cloud logout für die native Sitzung.

Umgang mit Geheimnissen

Bewahren Sie CI-Zugangsdaten im CI-Geheimnisspeicher auf und stellen Sie sie nur dem Schritt bereit, der sie benötigt.
Halten Sie Sitzungsverzeichnisse für ihren Eigentümer privat; nehmen Sie sie nicht in Versionskontrolle, benutzerübergreifende Caches oder veröffentlichte Artefakte auf.
Protokollieren Sie keine Token, Dienstgeheimnisse, Browser-Cookies oder vollständigen Umgebungen.
Deaktivieren Sie Shell-Tracing für Befehle mit Zugangsdaten und rotieren Sie jeden Wert, der in ein Protokoll gelangt sein könnte.

Remote-API-Zugriff

Verwenden Sie die typisierten Job- und Cloud-Befehle für das ausgewählte Backend. Client-Validierung und erfolgreiche Anmeldung ersetzen keine serverseitigen Berechtigungen und beweisen nicht, dass ein angeforderter Job abgeschlossen ist.

Die native Sitzung prüfen und wiederherstellen

alti ide cloud login
alti ide cloud whoami

Führen Sie diese Befehle als derselbe gewöhnliche Linux-Benutzer aus, der die CLI verwenden wird. Schließen Sie den Browserablauf ab und verlangen Sie eine erfolgreiche whoami-Antwort vor Workspace-Operationen. Wenn Sie ein alternatives --session-dir verwenden, nutzen Sie es für Login und nachfolgende Aufrufe; ein anderes Verzeichnis ist eine andere gespeicherte Sitzung.

Wenn die Sitzung abläuft, verwenden Sie den nativen Aktualisierungs-/Anmeldeablauf. Wenn die Identitätsprüfung erfolgreich ist, ein Projekt aber abgelehnt wird, prüfen Sie Organisationsmitgliedschaft und Projektberechtigungen. Kopieren Sie keine Desktop-Zugangsdaten und ändern Sie keine API-Origins, um die Ablehnung zu umgehen. Verwenden Sie für Kontowiederherstellung Kontosicherheit.