LogInClientCredentials
Nicht-interaktive Anmeldung über OAuth2 client_credentials. Liest die Anmeldedaten aus den Argumenten -id/-s oder aus den Umgebungsvariablen OCTO_CLI_CLIENT_ID/OCTO_CLI_CLIENT_SECRET. Der Tenant stammt aus dem aktiven Kontext.
Beispiele
Headless-Ausführung ΓÇö Anmeldedaten exportieren, dann anmelden:
octo-cli -c LogInClientCredentials
Oder direkt über Shell-Argumente (Argumente haben Vorrang vor Umgebungsvariablen):
octo-cli -c LogInClientCredentials -id "my-script-client" -s "<secret>"
Optionen
| Kurz | Lang | Erforderlich | Beschreibung |
|---|---|---|---|
-id | --clientId | nein | Client-ID. Fällt auf die Umgebungsvariable OCTO_CLI_CLIENT_ID zurück |
-s | --secret | nein | Client-Secret. Fällt auf die Umgebungsvariable OCTO_CLI_CLIENT_SECRET zurück |
Hinweise
Der Tenant stammt aus dem aktiven Kontext. Wechseln Sie den Kontext (z. B. octo-cli -c UseContext -n prod), um einen anderen Tenant anzusprechen. Die Anmeldung schlägt sofort fehl, wenn der aktive Kontext keine TenantId hat.
Der Client ist tenant-spezifisch. Wenn ein Skript mehrere Tenants ansprechen muss, erstellen Sie pro Tenant einen client_credentials-Client und wechseln Sie vor jeder Anmeldung den Kontext.
Es wird kein Refresh-Token ausgestellt (gemäß OAuth2-Spezifikation für client_credentials). Solange OCTO_CLI_CLIENT_ID und OCTO_CLI_CLIENT_SECRET in der Umgebung gesetzt bleiben, beschafft octo-cli das Token automatisch neu, wenn es abläuft ΓÇö langlaufende Skripte müssen LogInClientCredentials zwischen den Befehlen nicht erneut aufrufen. Sind die Umgebungsvariablen nicht gesetzt, gibt der nächste API-Aufruf nach Ablauf 401 zurück, und Sie müssen die Anmeldung erneut ausführen.
Das Token wird im Authentication-Block des aktiven Kontexts gespeichert, genau wie ein Device-Code-Token.