Skip to main content

​
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:
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:
client_id_variable is written as a bare quoted token — no curly braces. At query time Databrain replaces it with the clientId from the guest token.
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:
Both clientId and dataAppName are required on the v2 endpoint — the body is validated strictly. See the Guest Token reference for all optional fields.
This process combines secure access control with customized data visibility, aligning with user-specific requirements.