Working with Inboxes
Inboxes are a secure way for assigned members to receive encrypted inbound traffic from public sources.
Inboxes provide a secure way to receive entries from both internal and external sources.
- Entries can contain binary data and files.
- Each Context can contain any number of Inboxes with unique identifiers (
inboxId) used to distinguish them. - Everyone with access to
inboxID,solutionID, and Bridge URL can send an entry, but only the users who are added to given Inbox can read them.
Permissions
The user list in Inbox is designed to be flexible, accommodating a wide range of use cases.
Inboxes differentiate three types of users: Regular Users, Managers, and External Users. The table below shows what actions can be performed by each type of users:
| Activity | User | Manager | External |
|---|---|---|---|
| Submitting entries | yes | yes | yes |
| Listing entries | yes | yes | no |
| Deleting entries | no | yes | no |
| Editing Inbox | no | yes | no |
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.
Inbox publicMeta and privateMeta fields support any kind of data formats encoded to byte arrays.
Examples in this section use kotlinx-serialization-json-jvm dependency for Kotlin and com.google.code.gson:gson for Java to serialize object to JSON format.
Sample code on this page is based on the initial assumptions.
Working with Inboxes
To access Threads methods, get the field inboxApi from active connection. Connection should be initialized with Modules.INBOX and passed to PrivmxEndpoint().
Creating Inboxes
To create an Inbox, you need to name it and provide a list of public key - userID pairs.
Due to the fact that each Inbox is inside a Context, all the public keys have to be registered inside the given Context.
You can do it using Bridge API context/addUserToContext method.
While creating an Inbox, you can also provide additional information:
-
publicMetacontains additional info about the Inbox. It is not encrypted before sending to PrivMX Bridge. Inbox API provides methods for accessing this field aspublicView. For more information about InboxpublicViewand its common use cases go to Using Public View. -
privateMetathis field will be encrypted by PrivMX Endpoint before sending to PrivMX Bridge. It's meant to store additional sensitive information about the Inbox.privateMetais accessible only for users registered to the given Inbox. -
filesConfigyou can specify up front file requirements for each entry submitted to the Inbox. This config includes min and max count of files in an entry, their max size, but also max size of whole upload. -
policydetermines what actions will be available to specific users. For more information and use cases, go to Policies.
Public and private metadata is sent in binary format.
After creating an Inbox, all the users with management rights will be able to edit it. Skip to Modifying Inboxes for more info.
Creating a basic, unnamed Inbox, which can act as an encrypted data container:
Listing Inboxes
Your application may include multiple Inboxes, each associated with different Contexts. You can retrieve a list of all Inboxes within a given Context. This list, alongside the metadata you sent while creating the Inbox, will include useful metadata about the Inbox, such as the creation date, last file upload date, user list, and information about the last modification.
PrivMX Endpoint takes care of decrypting received data, which means you only have to take care of decoding them from binary format.
Define Inbox item class with decoded publicMeta and privateMeta:
Listing the most recent Inboxes in given Context:
Using Public View
Users with public connection (created by Connection.connectPublic)
have access to the Public View which shares not encrypted fields of the Inbox, such as publicMeta.
Modifying Inboxes
Depending on your project's specification, it may be necessary to modify an Inbox. It could be, for example, changing the name or adding/removing users. Each user with management rights is able to modify Inboxes, delete them as a whole or only particular entries.
Three additional options are available when changing the list of users inside an Inbox:
force- applies an update, without checking the current version.forceGenerateNewKey- re-encrypts entries in the Inbox. It's useful when a user is removed, and you want to prevent them from accessing the Inbox.policy- you can also pass a new policy object as the last optional argument.
Updating an Inbox means overwriting it with the provided data.
To successfully update an Inbox, 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.
To update an Inbox you must always provide its current version, as well as:
- list of users
- list of managers
- new private and public meta (even if it didn't change)
- Inbox's current version
- Inbox FilesConfig
trueif update action should be forced
We use cookies on our website. We use them to ensure proper functioning of the site and, if you agree, for purposes such as analytics, marketing, and targeting ads.
PrivMX Endpoint Java v2.6