Managing KVDBs
At their core, KVDBs provide a secure way for assigned members to exchange encrypted entries.
- KVDBs allow users to access key-value databases.
- Each Context can contain any number of KVDBs with a unique identifier (
kvdbId
) used to distinguish them. - KVDBs do not need to have unique names or assigned public keys.
Permissions
KVDBs differentiate two types of users - Managers and Regular Users. The table below shows the differences in their permissions:
Activity | User | Manager |
---|---|---|
Sending entries | yes | yes |
Editing KVDB | no | yes |
Deleting entries | only their own | all entries |
The values above are the default policy values defined by PrivMX. To read more about Policies and learn how to modify them, go to Policies.
Initial Assumptions
The initial assumptions for all the code examples below are as follows:
Creating KVDBs
To create a KVDB, you need a name and a list of public key - userID pairs. Due to the fact that each KVDB is inside a Context, all the public keys have to be registered inside the given Context. You can do it using PrivMX Bridge API.
After creating a KVDB, all the users with management rights will be able to edit the KVDB.
Below you can see some examples of creating KVDBs that function as a database feature in your application, with access management capabilities.
Listing KVDBs
Your application may include multiple KVDBs, each associated with different Contexts. You can retrieve a list of all KVDBs within a given Context. This list will include useful metadata about the KVDBs, such as the creation date, last message upload date, user list, and information about the last modification. However, to optimize performance, the list will only include the total number of entries in each KVDB, not the full entry content.
Here's an example of how to download the last 30 KVDBs created within a Context:
To limit collecting too much data when downloading KVDBs, specify the page index (starting from 0) and the number of items to be included on each page.
Modifying KVDBs
Depending on your project's specification, it may be necessary to modify a KVDB. It could be e.g. changing the name or adding/removing users. Each user with management rights is able to modify KVDB, delete them as a whole or only particular entries.
Updating a KVDB means overwriting it with the provided data.
To successfully update a KVDB, you must specify its current version
.
The version
field is mandatory to handle multiple updates on the server and it is incremented by 1 with each update.
Below there is an example of modifying a KVDB:
Three additional options are available when changing the list of users inside a KVDB:
force
- applies an update, without checking the current version;forceGenerateNewKey
- re-encrypts entries in the KVDB. It's useful when a user is removed and we want to prevent them from accessing the KVDB.policies
- allow you to manage access to KVDB and entries. Read more about Policies.
Deleting KVDBs
Deleting a KVDB means also removing all entries data of related deleted KVDB.
Below there is an example of deleting a KVDB:
We use cookies on our website. We use them to ensure the proper functioning of the site and, if you agree, for purposes we set, such as analytics or marketing.