User Management

The first step when creating a new user is to request a new account. This step is described elsewhere , because it is relevant for managers and consumers alike.

From BOMnipotent’s point of view, a user is associated with a unique email address or username, which is used as an identifier, and a public key, which is used for authentication. This is all the data sent during the creation of a new user account.

After a new account has been requested, it is up to a user manager to approve or deny the request.

For most user interactions, including listing, you need the USER_MANAGEMENT permission.

List

To list all users in your database, call

Input
bomnipotent_client user list
Output
[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 │
╰────────────────────────┴───────────┴─────────────────────────┴───────────┴─────────────────────────╯

You can see the email addresses or usernames of the users and their stati.

A user that does not have the status APPROVED has no special permissions, no matter which roles they have.

An expiration date is also associated with each user, which is the point in time at which the public key is considered invalid and has to be renewed. The period for which a key is considered valid can be freely configured in the server config.

The list of users can be filtered by username, approval status, and whether or not they are expired:

Input (long variant)
bomnipotent_client user list --user=admin@example.com --status=APPROVED --expired=false
Input (short variant)
bomnipotent_client user list -u admin@example.com -s APPROVED -e false
Output
[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 │
╰───────────────────┴──────────┴─────────────────────────┴───────────┴─────────────────────────╯

The “true” argument for the expired filter is optional:

Input (long variant)
bomnipotent_client user list --expired=true;
bomnipotent_client user list --expired # does the same
Input (short variant)
bomnipotent_client user list -e true;
bomnipotent_client user list -e # does the same
Output
[INFO] 
╭──────────┬────────┬─────────┬───────────┬──────────────╮
│ Username │ Status │ Expires │ User Type │ Last Updated │
├──────────┼────────┼─────────┼───────────┼──────────────┤
[INFO] 
╭──────────┬────────┬─────────┬───────────┬──────────────╮
│ Username │ Status │ Expires │ User Type │ Last Updated │
├──────────┼────────┼─────────┼───────────┼──────────────┤

Approve or Deny

If you were expecting the user request, you can approve it via

Input
bomnipotent_client user approve user@example.com
Output
[INFO] Changed status of user@example.com to APPROVED.

If the user has not yet verified their email address, the server denies the approval. If you are absolutely sure that you know what you are doing, you can overwrite this behaviour with the ‘–allow-unverified’ option (there’s no short version for options that bypass security measures):

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

If the account belongs to a robot, it can not be verified. In that case you can approve it with the ‘–robot’ option.

Input (long variant)
bomnipotent_client user approve example_robot --robot
Input (short variant)
bomnipotent_client user approve example_robot -r
Output
[INFO] Changed status of example_robot to APPROVED.

Important: You should be absolutely certain that this is the account you want to approve.

Analogously, you can decide agains allowing this user any special access:

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

Contrary to approval, this action does not care which status the user had before the denial.

It is possible to deny a user that has already been approved, effectively revoking the account.

A user whose previous request for an account was denied cannot request new user accounts.

Remove

If you want to get rid of a user account alltogether, call:

Input
bomnipotent_client user remove unwanted@example.com
Output
[INFO] Deleted user 'unwanted@example.com'.

This also removes all roles associated with the user.

Existence

The "exist" subcommand checks how many entries on the server match some filters. It is available for all commands that accept the "list" subcommand, and accepts the same filters.

Depending on the output mode, the client prints:

  • normal mode: a sentence including the number of found objects.
  • code: The string "200" if at least one item was found, or "404" if none were found.
  • raw: The number of entries that were found.
Input (long variant)
bomnipotent_client user exist --status=APPROVED
Input (short variant)
bomnipotent_client user exist -s APPROVED
Output
[INFO] The server contains 4 user(s) matching the filters.