Zugriffsverwaltung

Dokumente zur Lieferkettensicherheit sind das Was von BOMnipotent, Nutzer das Wer. Sofern Sie nicht ausdrücklich etwas anderes angeben, sind die gehosteten Dokumente nur für die Nutzerkonten sichtbar, welch von Ihnen Zugriff erahalten haben.

BOMnipotent verwendet rollenbasierte Zugriffskontrolle (RBAC): Nutzer haben Rollen, und Rollen haben Berechtigungen . Nach der Einrichtung enthält BOMnipotent einige Standardrollen. Diese reichen für die Serververwaltung aus. Um jedoch Nutzeranfragen annehmen zu können, sollten Sie mindestens eine neue Rolle erstellen .

Sobald dies erledigt ist, sieht ein typischer Workflow zur Einführung eines neuen Nutzers in Ihr BOMnipotent-System wie folgt aus:

  1. Ein neuer Nutzer erfragt Zugriff zu Ihrem Server. Dabei sendet der BOMnipotent-Client einen mit dem Konto verknüpften öffentlichen Schlüssel an Ihren Server, wo er gespeichert und als “REQUESTED” gekennzeichnet wird.
  2. Sie genehmigen die Anfrage. Das neue Benutzerkonto wird nun als gültig akzeptiert, verfügt aber noch über keine Berechtigungen.
  3. Sie weisen dem neuen Benutzerkonto eine oder mehrere Rollen zu.
22.03.2025

Unterabschnitte von Zugriffsverwaltung

Berechtigungen

In BOMnipotent sind Berechtigungen nicht direkt mit Benutzerkonten, sondern mit Rollen verknüpft. Der Abschnitt zur Rollenverwaltung beschreibt, wie diese Verknüpfung verwaltet wird, und der Abschnitt zur Rollenzuweisung erläutert, wie Rollen (und damit letztlich Berechtigungen) Benutzern zugewiesen werden.

Der Server verfügt über mehrere Berechtigungen im Code, von denen einige fest programmiert, andere konfigurierbar sind. Alle werden hier erläutert. Informationen zum Erstellen einer Berechtigung, die einer Rolle zugeordnet ist, finden Sie im entsprechenden Abschnitt .

Die Berechtigungen lassen sich gedanklich in Berechtigungen für Konsumenten , Manager und einige Sonderberechtigungen für Administratoren unterteilen.

Berechtigungen für Konsumenten

Ihre Kunden sind in der Regel mit einem oder mehreren Ihrer Produkte verknüpft. Sie möchten alle Arten von Dokumenten und Informationen zu diesem Produkt einsehen, haben aber nicht automatisch Anspruch auf Informationen zu anderen Produkten.

PRODUCT_ACCESS

Eine Berechtigung mit dem Wert “PRODUCT_ACCESS(<PRODUCT>)” gewährt Leseberechtigung für alle mit “<PRODUCT>” verknüpften Dokumente. Dies umfasst alle Stücklisten (BOMs) dieses Produkts, alle damit verbundenen Schwachstellen und alle CSAF-Dokumente zu diesem Produkt.

Beispielsweise könnte eine Rolle mit dem Wert “PRODUCT_ACCESS(BOMnipotent)” alle mit BOMnipotent verknüpften Dokumente (und nur diese) einsehen.

Dem Sternchen-Operator “*” kann als Globbing-Platzhalter für Produktnamen genutzt werden. Dabei entspricht das Sternchen einer beliebigen Anzahl von Symbolen. Beispielsweise würde die Berechtigung “PRODUCT_ACCESS(BOM*ent)” sowohl auf “BOMnipotent” als auch auf die (fiktiven) Produkte “BOMent” und “BOM-burárum-ent” zutreffen, nicht jedoch auf “BOMtastic” (da letzteres nicht auf “ent” endet).

Folglich ermöglicht “PRODUCT_ACCESS(*)” die Anzeige aller Dokumente.

Berechtigungen für Manager

Für Dokumentmanager ist die Situation in der Regel umgekehrt: Sie benötigen die Berechtigung, die Datenbankinhalte nicht nur anzuzeigen, sondern auch zu ändern. Ihr Umfang ist typischerweise nicht auf ein bestimmtes Produkt, sondern auf einen bestimmten Dokumenttyp beschränkt. Daher wird die Trennung der Managerberechtigungen aus einer anderen Perspektive betrachtet.

BOM_MANAGEMENT

Diese Berechtigung ermöglicht das Hochladen, Ändern und Löschen von Stücklisten (BOMs). Sie gewährt automatisch auch die Berechtigung zur Anzeige aller gehosteten Stücklisten.

VULN_MANAGEMENT

Diese Berechtigung ermöglicht das Aktualisieren und Anzeigen der Liste der Schwachstellen, die mit einer BOM verknüpft sind.

CSAF_MANAGEMENT

Diese Berechtigung ermöglicht das Hochladen, Ändern und Löschen von CSAF-Dokumenten (Common Security Advisory Framework). Sie gewährt außerdem automatisch Anzeigeberechtigungen für alle gehosteten CSAF-Dokumente.

ROLE_MANAGEMENT

Mit dieser Berechtigung kann ein Benutzer die Berechtigungen von Rollen ändern . Dies kann weitreichende Folgen haben, da die Änderungen potenziell viele Benutzer betreffen.

USER_MANAGEMENT

Diese Berechtigung ist erforderlich, um Benutzer anzuzeigen, oder ihre Anfragen zur Kontoerstellung zu gewähren oder abzulehnen . Sie wird auch benötigt, um Nutzern Rollen zuzuweisen .

Sonderberechtigungen für Administratoren

BOMnipotent kennt die feststehende Rolle “admin”. Diese Rolle verfügt stets über alle Berechtigungen, die Benutzern erteilt werden können. Darüber hinaus gibt es einige Aufgaben, die nur von Benutzern mit der Administratorrolle ausgeführt werden können: – Nur Administratoren können die Administratorrolle anderen Benutzern zuweisen oder entziehen . Ein spezieller temporärer Administratormechanismus ermöglicht die Erstellung des ersten Administrators für einen neu erstellten BOMnipotent Server. – Nur Administratoren können den Abonnementschlüssel für eine BOMnipotent Server Instanz (de)aktivieren .

21.05.2025

Rollenverwaltung

BOMnipotent verwendet ein rollenbasiertes Zugriffsmodell (RBAC), bei dem Benutzer Rollen und Rollen Berechtigungen zugeordnet werden. Während Berechtigungen in BOMnipotent größtenteils fest kodiert sind, können Rollen (fast) frei verwaltet werden. Dieser Abschnitt erklärt, wie das geht.

Um Rollen und ihre Berechtigungen zu ändern oder anzuzeigen, benötigt Ihr Benutzerkonto die Berechtigung ROLE_MANAGEMENT.

Standardrollen

Beim ersten Start Ihres BOMnipotent Servers werden in der Datenbank mehrere kreativ benannte Standardrollen angelegt:

Sie können diese Rollen nach Belieben ändern oder löschen; es handelt sich lediglich um Vorschläge.

Wenn Ihnen diese Rollen nicht gefallen, können Sie sie mit den folgenden Aufrufen löschen:

Eingabe
bomnipotent_client role-permission remove bom_manager BOM_MANAGEMENT;
bomnipotent_client role-permission remove csaf_manager CSAF_MANAGEMENT;
bomnipotent_client role-permission remove role_manager ROLE_MANAGEMENT;
bomnipotent_client role-permission remove user_manager USER_MANAGEMENT;
bomnipotent_client role-permission remove vuln_manager VULN_MANAGEMENT;
Ausgabe
[INFO] Removed permission BOM_MANAGEMENT from role bom_manager.
[INFO] Removed permission CSAF_MANAGEMENT from role csaf_manager.
[INFO] Removed permission ROLE_MANAGEMENT from role role_manager.
[INFO] Removed permission USER_MANAGEMENT from role user_manager.
[INFO] Removed permission VULN_MANAGEMENT from role vuln_manager.

Admin-Rolle

Es gibt eine spezielle Rolle namens “admin”, die nicht in den anderen Rollen aufgeführt ist. Der Grund dafür ist, dass sie nicht Teil der Datenbank, sondern des BOMnipotent-Codes selbst ist. Daher kann sie nicht geändert werden.

Eingabe
bomnipotent_client role-permission remove admin BOM_MANAGEMENT
Ausgabe
[ERROR] Received response:
422 Unprocessable Entity
Cannot modify admin role permissions.

Die Administratorrolle verfügt über alle Berechtigungen, die erteilt werden können, und dann noch einige weitere .

Auflisten

Um alle Rollen und die zugehörigen Berechtigungen aufzulisten, rufen Sie Folgendes auf:

Eingabe
bomnipotent_client role-permission list
Ausgabe
[INFO] 
╭──────────────┬─────────────────┬─────────────────────────╮
│ Role         │ Permission      │ Last Updated            │
├──────────────┼─────────────────┼─────────────────────────┤
│ bom_manager  │ BOM_MANAGEMENT  │ 2025-01-01 10:11:12 UTC │
│ csaf_manager │ CSAF_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
│ role_manager │ ROLE_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
│ user_manager │ USER_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
│ vuln_manager │ VULN_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
╰──────────────┴─────────────────┴─────────────────────────╯

Die Ausgabe kann nach Rolle oder Berechtigung gefiltert werden:

Eingabe (lange Variante)
bomnipotent_client role-permission list --role=bom_manager --permission=BOM_MANAGEMENT
Eingabe (kurze Variante)
bomnipotent_client role-permission list -r bom_manager -p BOM_MANAGEMENT
Ausgabe
[INFO] 
╭─────────────┬────────────────┬─────────────────────────╮
│ Role        │ Permission     │ Last Updated            │
├─────────────┼────────────────┼─────────────────────────┤
│ bom_manager │ BOM_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
╰─────────────┴────────────────┴─────────────────────────╯

Hinzufügen

Da Rollen ohne Berechtigungen bedeutungslos sind, werden sie immer paarweise verwendet. Es gibt keinen speziellen Mechanismus zum Erstellen einer neuen Rolle. Stattdessen existiert eine Rolle dadurch, dass ihr eine Berechtigung hinzugefügt wird.

Die Syntax zum Hinzufügen einer Berechtigung zu einer Rolle lautet:

Eingabe
bomnipotent_client role-permission add rick_role "PRODUCT_ACCESS(BOMnipotent)"
Ausgabe
[INFO] Added permission PRODUCT_ACCESS(BOMnipotent) to role rick_role.

Sie könnten beispielsweise mehrere Berechtigungen in den Rollen “doc_manager” und “access_manager” zusammenfassen:

Eingabe
bomnipotent_client role-permission add doc_manager BOM_MANAGEMENT;
bomnipotent_client role-permission add doc_manager CSAF_MANAGEMENT;
bomnipotent_client role-permission add doc_manager VULN_MANAGEMENT;
bomnipotent_client role-permission add access_manager ROLE_MANAGEMENT;
bomnipotent_client role-permission add access_manager USER_MANAGEMENT;
Ausgabe
[INFO] Added permission BOM_MANAGEMENT to role doc_manager.
[INFO] Added permission CSAF_MANAGEMENT to role doc_manager.
[INFO] Added permission VULN_MANAGEMENT to role doc_manager.
[INFO] Added permission ROLE_MANAGEMENT to role access_manager.
[INFO] Added permission USER_MANAGEMENT to role access_manager.

Falls Sie die Standardrollen wie oben beschrieben entfernt haben, erhalten Sie damit folgenden Zustand:

Eingabe
bomnipotent_client role-permission list
Ausgabe
[INFO] 
╭────────────────┬─────────────────┬─────────────────────────╮
│ Role           │ Permission      │ Last Updated            │
├────────────────┼─────────────────┼─────────────────────────┤
│ access_manager │ ROLE_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
│ access_manager │ USER_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
│ doc_manager    │ BOM_MANAGEMENT  │ 2025-01-01 10:11:12 UTC │
│ doc_manager    │ CSAF_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
│ doc_manager    │ VULN_MANAGEMENT │ 2025-01-01 10:11:12 UTC │
╰────────────────┴─────────────────┴─────────────────────────╯

Falls die hinzuzufügende Berechtigung nicht existiert oder fehlerhaft ist, erhalten Sie eine Fehlermeldung:

Eingabe
bomnipotent_client role-permission add clam_manager CLAM_MANAGEMENT
Ausgabe
[ERROR] Received response:
422 Unprocessable Entity
Failed to parse permission: Invalid UserPermission string: CLAM_MANAGEMENT

Entfernen

Um eine Berechtigung aus einer Rolle zu entfernen, rufen Sie einfach Folgendes auf:

Eingabe
bomnipotent_client role-permission remove rick_role "PRODUCT_ACCESS(BOMnipotent)"
Ausgabe
[INFO] Removed permission PRODUCT_ACCESS(BOMnipotent) from role rick_role.

Sobald Sie die letzte Rolle aus einer Berechtigung entfernt haben, existiert diese nicht mehr.

Um Hoppla-Momente zu vermeiden, unterstützt BOMnipotent nicht das Löschen ganzer Stapel von Rollenberechtigungen.

Existenz

Der Sub-Befehl "exist" prüft, wie viele Einträge auf dem Server mit bestimmten Filtern übereinstimmt. Er ist für alle Befehle verfügbar, die den "list" Sub-Befehl akzeptieren, und akzeptiert dieselben Filter.

Basierend auf dem Ausgabeformat gibt der Client Folgendes aus:

  • Normaler Modus: Ein Satz, der die Anzahl der gefundenen Objekte enthält.
  • code: Den String "200", falls mindestens ein Element gefunden wurde, oder "404", falls keine gefunden wurden.
  • raw: Die Anzahl der Einträge, die gefunden wurden.
Eingabe (lange Variante)
bomnipotent_client role-permission exist --role=bom_manager
Eingabe (kurze Variante)
bomnipotent_client role-permission exist -r bom_manager
Ausgabe
[INFO] The server contains 1 role permission(s) matching the filters.
18.07.2025

Nutzerverwaltung

Der erste Schritt beim Anlegen eines neuen Benutzers ist die Beantragung eines neuen Kontos. Dieser Schritt wird an anderer Stelle beschrieben, da er sowohl für Manager als auch für Konsumenten relevant ist.

Aus Sicht von BOMnipotent ist ein Benutzer verknüpft mit einer eindeutigen E-Mail-Adresse als Kennung, und einem öffentlichen Schlüssel zur Authentifizierung. Dies sind alle Daten, die bei der Erstellung eines neuen Benutzerkontos gesendet werden.

Nach der Beantragung eines neuen Kontos obliegt es einem Benutzermanager, die Anfrage zu genehmigen oder abzulehnen.

Für die meisten Benutzerinteraktionen, einschließlich der Auflistung, benötigen Sie die Berechtigung USER_MANAGEMENT.

Auflisten

Um alle Benutzer in Ihrer Datenbank aufzulisten, rufen Sie

Eingabe
bomnipotent_client user list
Ausgabe
[INFO] 
╭────────────────────────┬───────────┬─────────────────────────┬───────────┬─────────────────────────╮
│ Username               │ Status    │ Expires                 │ User Type │ Last Updated            │
├────────────────────────┼───────────┼─────────────────────────┼───────────┼─────────────────────────┤
│ admin@example.com      │ APPROVED  │ 2025-01-01 10:11:12 UTC │ HUMAN     │ 2025-01-01 10:11:12 UTC │
│ example_robot          │ REQUESTED │ 2025-01-01 10:11:12 UTC │ ROBOT     │ 2025-01-01 10:11:12 UTC │
│ other_user@example.com │ REQUESTED │ 2025-01-01 10:11:12 UTC │ HUMAN     │ 2025-01-01 10:11:12 UTC │
│ user@example.com       │ VERIFIED  │ 2025-01-01 10:11:12 UTC │ HUMAN     │ 2025-01-01 10:11:12 UTC │
╰────────────────────────┴───────────┴─────────────────────────┴───────────┴─────────────────────────╯

So können Sie die E-Mail-Adressen und die Stati der Benutzer einsehen.

Ein Benutzer ohne den Status “APPROVED” hat keine besonderen Berechtigungen, unabhängig von zugewiesenen Rollen.

Jedem Benutzer ist außerdem ein Ablaufdatum zugeordnet. Ab diesem Zeitpunkt wird der öffentliche Schlüssel ungültig und muss erneuert werden. Die Gültigkeitsdauer eines Schlüssels kann in der Serverkonfiguration frei konfiguriert werden.

Die Liste der Nutzer kann nach Nutzername oder Genehmigungsstatus gefiltert werden, oder danach, ob das Nutzerkonto abgelaufen ist:

Eingabe (lange Variante)
bomnipotent_client user list --user=admin@example.com --status=APPROVED --expired=false
Eingabe (kurze Variante)
bomnipotent_client user list -u admin@example.com -s APPROVED -e false
Ausgabe
[INFO] 
╭───────────────────┬──────────┬─────────────────────────┬───────────┬─────────────────────────╮
│ Username          │ Status   │ Expires                 │ User Type │ Last Updated            │
├───────────────────┼──────────┼─────────────────────────┼───────────┼─────────────────────────┤
│ admin@example.com │ APPROVED │ 2025-01-01 10:11:12 UTC │ HUMAN     │ 2025-01-01 10:11:12 UTC │
╰───────────────────┴──────────┴─────────────────────────┴───────────┴─────────────────────────╯

Das “true” Argument für den “expired” Filter ist optional:

Eingabe (lange Variante)
bomnipotent_client user list --expired=true;
bomnipotent_client user list --expired # does the same
Eingabe (kurze Variante)
bomnipotent_client user list -e true;
bomnipotent_client user list -e # does the same
Ausgabe
[INFO] 
╭──────────┬────────┬─────────┬───────────┬──────────────╮
│ Username │ Status │ Expires │ User Type │ Last Updated │
├──────────┼────────┼─────────┼───────────┼──────────────┤
[INFO] 
╭──────────┬────────┬─────────┬───────────┬──────────────╮
│ Username │ Status │ Expires │ User Type │ Last Updated │
├──────────┼────────┼─────────┼───────────┼──────────────┤

Genehmigen oder Ablehnen

Wenn Sie die Benutzeranfrage erwartet haben, können Sie sie genehmigen:

Eingabe
bomnipotent_client user approve user@example.com
Ausgabe
[INFO] Changed status of user@example.com to APPROVED.

Falls der Nutzer noch nicht bestätigt hat, Zugriff auf die Email Adresse zu haben, dann lehnt der Server die Genehmigung ab. Falls Sie absolut sicher sind, dass Sie wissen was Sie tun, können Sie dieses Verhalten mit der ‘–allow-unverified’ Option überschreiben (es gibt keine Kurzformen für Befehle die Sicherheitsmaßnahmen überschreiben):

Eingabe
bomnipotent_client user approve other_user@example.com --allow-unverified
Ausgabe
[INFO] Changed status of other_user@example.com to APPROVED.

Falls das Konto zu einem Roboter gehört, kann es nicht verifiziert werden. In diesem Fall können Sie es mit der ’ –robot’ Option genehmigen:

Eingabe (lange Variante)
bomnipotent_client user approve example_robot --robot
Eingabe (kurze Variante)
bomnipotent_client user approve example_robot -r
Ausgabe
[INFO] Changed status of example_robot to APPROVED.

Wichtig: Sie sollten absolut sicher sein, dass dies das Konto ist, welches Sie genehmigen wollen.

Analog dazu können Sie diesem Benutzer stattdessen keinen Zugriff gewähren:

Eingabe
bomnipotent_client user deny unwanted@example.com
Ausgabe
[INFO] Changed status of unwanted@example.com to DENIED.

Im Gegensatz zum Genehmigen ist es dieser Aktion egal, welchen Status das Konto vor der Ablehnung hatte.

Es ist möglich, einem bereits genehmigten Benutzer den Zugriff wieder zu verweigern, wodurch das Konto effektiv widerrufen wird.

Ein Nutzer, dessen vorherige Anfrage für einen Nutzeraccount abgelehnt wurde, kann keine weiteren Nutzeraccounts anfragen.

Entfernen

Wenn Sie ein Benutzerkonto vollständig löschen möchten, rufen Sie

Eingabe
bomnipotent_client user remove unwanted@example.com
Ausgabe
[INFO] Deleted user 'unwanted@example.com'.

Dies löscht zusätzlich alle dem Benutzer zugewiesenen Rollen.

Existenz

Der Sub-Befehl "exist" prüft, wie viele Einträge auf dem Server mit bestimmten Filtern übereinstimmt. Er ist für alle Befehle verfügbar, die den "list" Sub-Befehl akzeptieren, und akzeptiert dieselben Filter.

Basierend auf dem Ausgabeformat gibt der Client Folgendes aus:

  • Normaler Modus: Ein Satz, der die Anzahl der gefundenen Objekte enthält.
  • code: Den String "200", falls mindestens ein Element gefunden wurde, oder "404", falls keine gefunden wurden.
  • raw: Die Anzahl der Einträge, die gefunden wurden.
Eingabe (lange Variante)
bomnipotent_client user exist --status=APPROVED
Eingabe (kurze Variante)
bomnipotent_client user exist -s APPROVED
Ausgabe
[INFO] The server contains 4 user(s) matching the filters.
18.07.2025

Rollenzuweisung

Rollen verbinden Benutzer mit Berechtigungen. Das Hinzufügen oder Entfernen von Rollen steuert indirekt, in welchem ​​Umfang Benutzer mit Ihrer BOMnipotent Server Instanz interagieren können.

Zu Ihrer Bequemlichkeit werden beim ersten Start des BOMnipotent-Servers mehrere Standardrollen angelegt. BOMnipotent kennt außerdem die Administratorrolle , die eine besondere Behandlung erhält.

Um Benutzerrollen zu ändern oder anzuzeigen, benötigt Ihr Benutzerkonto die Berechtigung USER_MANAGEMENT.

Auflisten

Um alle Rollen aller Benutzer aufzulisten, rufen Sie

Eingabe
bomnipotent_client user-role list
Ausgabe
[INFO] 
╭───────────────────┬──────────────┬─────────────────────────╮
│ Username          │ Role         │ Last Updated            │
├───────────────────┼──────────────┼─────────────────────────┤
│ admin@example.com │ admin        │ 2025-01-01 10:11:12 UTC │
│ example_robot     │ bom_manager  │ 2025-01-01 10:11:12 UTC │
│ example_robot     │ vuln_manager │ 2025-01-01 10:11:12 UTC │
│ user@example.com  │ rick_role    │ 2025-01-01 10:11:12 UTC │
╰───────────────────┴──────────────┴─────────────────────────╯

Die Ausgabe kann nach Nutzer oder Rolle gefiltert werden:

Eingabe (lange Variante)
bomnipotent_client user-role list --user=admin@example.com --role=admin
Eingabe (kurze Variante)
bomnipotent_client user-role list -u admin@example.com -r admin
Ausgabe
[INFO] 
╭───────────────────┬───────┬─────────────────────────╮
│ Username          │ Role  │ Last Updated            │
├───────────────────┼───────┼─────────────────────────┤
│ admin@example.com │ admin │ 2025-01-01 10:11:12 UTC │
╰───────────────────┴───────┴─────────────────────────╯

Hinzufügen

Um einem Benutzer eine neue Rolle hinzuzufügen, rufen Sie

Eingabe
bomnipotent_client user-role add user@example.com rick_role
Ausgabe
[INFO] Added role to user.

Der Benutzeraccount muss zu diesem Zeitpunkt bereits auf dem Server existieren, die Rolle jedoch nicht.

Nur Benutzer mit der Admin-Rolle können anderen Benutzern die Admin-Rolle zuweisen.

Entfernen

Um einem Benutzer eine Rolle zu entfernen, rufen Sie Folgendes auf:

Eingabe
bomnipotent_client user-role remove user@example.com rick_role
Ausgabe
[INFO] Removed role rick_role from user user@example.com.

Wenn eine der beiden Rollen nicht vorhanden ist, wird ein Fehler angezeigt:

Eingabe
bomnipotent_client user-role remove admin@example.com wrong_role;
bomnipotent_client user-role remove wrong_user admin
Ausgabe
[ERROR] Received response:
404 Not Found
User with username 'admin@example.com' does not have role wrong_role.
[ERROR] Received response:
404 Not Found
No user with username 'wrong_user' was found: Record not found

Nur Benutzer mit der Admin-Rolle können die Admin-Rolle von anderen Benutzern entfernen.

Existenz

Der Sub-Befehl "exist" prüft, wie viele Einträge auf dem Server mit bestimmten Filtern übereinstimmt. Er ist für alle Befehle verfügbar, die den "list" Sub-Befehl akzeptieren, und akzeptiert dieselben Filter.

Basierend auf dem Ausgabeformat gibt der Client Folgendes aus:

  • Normaler Modus: Ein Satz, der die Anzahl der gefundenen Objekte enthält.
  • code: Den String "200", falls mindestens ein Element gefunden wurde, oder "404", falls keine gefunden wurden.
  • raw: Die Anzahl der Einträge, die gefunden wurden.
Eingabe (lange Variante)
bomnipotent_client user-role exist --role=bom_manager
Eingabe (kurze Variante)
bomnipotent_client user-role exist -r bom_manager
Ausgabe
[INFO] The server contains 1 user role(s) matching the filters.