Permission Examples

Worked examples for the most common permission patterns. The table examples build on the Permissions overview and use the same todos table (id, title, user_id).

Insert Permissions

Here is a popular approach for insert permission for authenticated users.

1. At the top of the page, click insert on the user role.
2. Select Without any checks.
3. Select the columns you want to allow users to insert. In our example, we do not mark id nor user_id, because they should not be inserted by the user. The id is automatically generated by the database and user_id is set using a column preset.
4. Under Column presets, set user_id to x-hasura-user-id. This way, every new record’s user_id value is set to the ID of the user making the request.

Now, authenticated users are allowed to insert todos. Users are allowed to add a title when inserting a todo. The todo’s id is automatically generated by the database and the user_id is automatically set to the user’s id using the user_id = x-hasura-user-id column preset.

Select, Update and Delete Permissions

Select, update, and delete permissions usually follow the same pattern. Here’s an example of how to add select permissions:

One of the most common permission requirements is that authenticated users should only be able to read their own data. This is how to do that:

1. Go to the Database section in the Nhost Dashboard.
2. In the context menu of the table you want to edit, click on Edit Permissions.
3. Click on the role and operation you want to set.
4. Select With custom check to create a new rule.
5. Enter user_id, _eq and x-hasura-user-id into the rule form. This means that in order for users to read data, the user ID value in the database row must be the same as the user ID in the access token.
6. Limit the number of rows to 100 (or some other relevant number).
7. Select the columns you want the user to be able to read. In our case, we’ll allow the user to read all columns.
8. Click Save.

Note

The per-role row limit is enforced by the default engine. Constellation currently parses it but does not enforce it, so if you rely on a hard row cap, also enforce it in your query (limit:) or application logic.

Action Permissions

Actions are permissioned per role too, but the rules are simpler: a role either can call the Action or it cannot. By default, only the admin role can.

1. Go to the GraphQL > Actions section in the Nhost Dashboard.

2. In the ⋯ menu of the Action you want to edit, click Edit Permissions.

3. Click a permission cell to toggle whether that role is allowed to call the Action.
4. Click Allow.

The admin role is always allowed, and the public role is available for unauthenticated access. There are no column-level rules or row checks, because an Action resolves through your webhook rather than a table. Any filtering of what the caller may see belongs in the handler.

To add or remove the roles listed here, go to Settings > Roles and Permissions.