Authentifizierung

Jede Anfrage, die die CLI sendet, trägt einen API-Schlüssel Ihres Projekts. Speichern Sie Schlüssel einmal mit status200 login, einen Kontext für jede Umgebung, oder geben Sie sie einem Befehl in Flags oder Umgebungsvariablen mit, wie es Skripte tun. Diese Seite zeigt jeden Weg und welchen ein Befehl nimmt, wenn es mehrere gibt.

Bevor Sie beginnen#

Sie brauchen einen API-Schlüssel Ihres Projekts. Legen Sie einen unter Projekteinstellungen → Erweitert → API-Schlüssel mit API-Schlüssel erstellen an und geben Sie ihm den Zugriff, den Ihre Befehle brauchen: siehe Einen API-Schlüssel anlegen. Ein Schlüssel tut, was seine Berechtigungen erlauben: Ein Schlüssel, der Datensätze nur lesen darf, kann sie auflisten und lesen, aber nicht ändern.

In Status200 Cloud funktionieren API-Schlüssel nur, solange das Projekt im Tarif Growth oder höher ist. Darunter antwortet jeder Befehl mit API error (402) und einer Meldung, die den Tarif nennt, bis das Projekt hochgestuft wird; dann funktioniert derselbe Schlüssel wieder. Siehe API-Schlüssel und SCIM unterhalb ihres Tarifs.

Anmelden#

status200 login speichert einen API-Schlüssel und die Adresse Ihrer Status200-Instanz als Kontext und macht ihn zum aktuellen Kontext:

status200 login <api-key> <instance-url> [--context-name <name>]

Zum Beispiel ein Kontext namens production:

status200 login <api-key> https://status200.ru --context-name production

Sie antwortet Logged in successfully. Context "production" is now active. Ein Schrägstrich am Ende der Adresse wird entfernt, und eine erneute Anmeldung unter demselben Namen ersetzt diesen Kontext.

Kontexte#

Ein Kontext ist eine gespeicherte Anmeldung: ein Name, eine Adresse und ein API-Schlüssel. Speichern Sie einen für jedes Projekt oder jede Umgebung und wählen Sie dann einen für alle folgenden Befehle oder für einen einzelnen Befehl.

1. Einen Kontext für jede Umgebung speichern#

   Bash

   status200 login <production-api-key> https://status200.ru --context-name production
   status200 login <staging-api-key> https://status200.example.com --context-name staging

   Jede Anmeldung macht ihren Kontext zum aktuellen, also ist jetzt staging aktuell.

2. Die Kontexte auflisten#

   Bash

   status200 context list

   ┌───┬────────────┬───────────────────────────────┐
   │   │ Name       │ URL                           │
   ├───┼────────────┼───────────────────────────────┤
   │   │ production │ https://status200.ru          │
   ├───┼────────────┼───────────────────────────────┤
   │ * │ staging    │ https://status200.example.com │
   └───┴────────────┴───────────────────────────────┘

   Das * markiert den aktuellen Kontext. API-Schlüssel werden nie aufgelistet.

3. Zu einem anderen Kontext wechseln#

   Bash

   status200 context use production

   Sie antwortet Switched to context "production". und die folgenden Befehle verwenden ihn.

4. Einen Kontext für einen einzelnen Befehl verwenden#

   Bash

   status200 incident list --context staging

   Der aktuelle Kontext bleibt, wie er war.

Welche Anmeldedaten ein Befehl verwendet#

Ein Befehl braucht einen API-Schlüssel und eine URL. Beides nimmt er jeweils vom ersten dieser Orte, der einen Wert hat:

Sie können sie also mischen: etwa einen API-Schlüssel aus einer Umgebungsvariable mit der URL des aktuellen Kontexts. Umgebungsvariablen passen zu Skripten und CI-Jobs, die keine gespeicherten Kontexte haben:

export STATUS200_API_KEY=<api-key>
export STATUS200_URL=https://status200.ru
status200 incident list

export STATUS200_API_KEY=<api-key>
export STATUS200_URL=https://status200.ru
status200 incident list

$env:STATUS200_API_KEY = "<api-key>"
$env:STATUS200_URL = "https://status200.ru"
status200 incident list

Flags gehen allem anderen vor, für einen einzelnen Befehl:

status200 --api-key <api-key> --url https://status200.ru incident list

Prüfen, was die CLI verwenden wird#

status200 whoami zeigt die URL und den API-Schlüssel, die der nächste Befehl verwendet, und den Kontext, aus dem sie stammen:

status200 whoami

URL:     https://status200.ru
API Key: 4f1c****0a13
Context: production

Vom Schlüssel werden nur die ersten vier und die letzten vier Zeichen gezeigt. Die Zeile Context erscheint nur, wenn URL und Schlüssel die eigenen Werte dieses Kontexts sind, keine, die ein Flag oder eine Umgebungsvariable ersetzt hat. whoami liest Ihre Einstellungen, ohne Status200 aufzurufen: Es zeigt, was ein Befehl senden wird, nicht ob Status200 es annimmt. Ist nichts gespeichert oder gesetzt, antwortet es:

Not authenticated. Run `status200 login` to authenticate.

Die Konfigurationsdatei#

status200 login speichert Kontexte in ~/.oneuptime/config.json, in Ihrem Home-Verzeichnis (%USERPROFILE%\.oneuptime\config.json unter Windows). Die CLI legt die Datei so an, dass nur Ihr Benutzer sie lesen und schreiben kann (Modus 0600):

{
  "currentContext": "production",
  "contexts": {
    "production": {
      "name": "production",
      "apiUrl": "https://status200.ru",
      "apiKey": "<api-key>"
    },
    "staging": {
      "name": "staging",
      "apiUrl": "https://status200.example.com",
      "apiKey": "<api-key>"
    }
  }
}

Die Datei enthält die API-Schlüssel, wie sie sind: Halten Sie sie aus geteilten Ordnern, Backups und Repositories heraus. Um sich von einem Kontext abzumelden, löschen Sie ihn mit status200 context delete <name>; um sich von allen abzumelden, löschen Sie die Datei. Ein Schlüssel, der durchgesickert sein könnte, bleibt gültig, bis Sie ihn in Status200 löschen, unter Projekteinstellungen → Erweitert → API-Schlüssel.

Ausgabeformate und Listengrößen werden hier nicht gespeichert: Geben Sie -o und --limit jedem Befehl mit.

Fehlerbehebung#

Nächste Schritte#