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
bomnipotent_client user list
[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:
bomnipotent_client user list --user=admin@example.com --status=APPROVED --expired=false
bomnipotent_client user list -u admin@example.com -s APPROVED -e false
[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:
bomnipotent_client user list --expired=true;
bomnipotent_client user list --expired # does the same
bomnipotent_client user list -e true;
bomnipotent_client user list -e # does the same
[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
bomnipotent_client user approve user@example.com
[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):
bomnipotent_client user approve other_user@example.com --allow-unverified
[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.
bomnipotent_client user approve example_robot --robot
bomnipotent_client user approve example_robot -r
[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:
bomnipotent_client user deny unwanted@example.com
[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:
bomnipotent_client user remove unwanted@example.com
[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.
bomnipotent_client user exist --status=APPROVED
bomnipotent_client user exist -s APPROVED
[INFO] The server contains 4 user(s) matching the filters.