​
How Our Row-Level Policies Work?

Set row-level policies for each table using your data source’s SQL language. DataBrain parses and applies these policies as Common Table Expressions (CTEs) during query generation. This step happens post-validation, just before sending the query to your database or warehouse. This method ensures user-specific data access, e.g., User A sees only their data. You can also define and assign dynamic variables in your SQL queries during token creation.

​
Guest Token

For a user to view the embedded DataBrain dashboard in your application, your backend must request a guest token from DataBrain. This request is specific to the user and utilizes their userId or clientId. Example request payload: 
{ 
  "clientId": "7807dcd1-1919-474b-aba7-7f23a062d02f" 
}
These identifiers are then injected into your row-level policies, tailoring the data returned to the user based on these parameters.

​
Example of Implementing a Row-Level Policy

To ensure each user only sees data relevant to them in a consumers table, you would set up a row-level policy and create a specific token. Here’s how you can do it:

​
Step 1: Defining the Row-Level Policy for the Customers Table

Write a SQL query to define the policy: 
SELECT * FROM consumers WHERE id = '{client_id_variable}'
This query ensures that each user only accesses rows in the consumers table where their unique identifier matches the id column.

​
Step 2: Generating a Token

Use a curl command to generate a token for a specific user: 
curl -X POST --location 'https://api.usedatabrain.com/api/v1/guest-tokens' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer <API-KEY>' \
--data '{ "clientId": "7807dcd1-1919-474b-aba7-7f23a062d02f" }'
This process combines secure access control with customized data visibility, aligning with user-specific requirements.