Sign up for Hasura Newsletter
Loading...

Permissions for Threads and Messages

We are done with rules for all the base tables (users, workspace and channel). The primary part of slack is for users to send and receive messages on the channel or to other users. Let's see how that is applicable in the access control rules.

Let's start with the channel_thread and channel_thread_message tables.

Select permission

We need to list down who can access a message posted on any channel. The requirement looks like:

  • Any body who is a channel member should be able to access all channel threads.

Row level select

The expression for channel_thread roughly translates to the following:

{
"channel": {
"channel_members": {
"user_id": {
"_eq": "X-Hasura-User-Id"
}
}
}
}

The expression differs slighlty for channel_thread_message since it has one more level of nesting.

{
"channel_thread": {
"channel": {
"channel_members": {
"user_id": {
"_eq": "X-Hasura-User-Id"
}
}
}
}
}

Column level select

After filtering out the rows that a user is supposed to access, we need to filter out which fields they are allowed to read. Since there is no sensitive data that needs to be restricted to only a certain type of user, we give permission to select for ALL columns.

We are done with read access. Let's move on to write access which lets a user to either create, update or delete a channel.

Insert permission

Any authenticated user who is a part of a workspace can post messages on the channels of the workspace. It translates into the same expression as above for channel_thread table.

Update permission

Users are not allowed to update a channel_thread. So then who is allowed to update the existing messages in channel_thread_message table?

  • Any authenticated user can update their own message posted on any channel.

Row level update

The above condition translates to the following expression:

{
"user_id": {
"_eq": "X-Hasura-User-Id"
}
}

Column level update

The user can only update the message column in channel_thread_message table.

Delete permission

The user who created the message can delete their own message. It translates to the same expression that we defined for the update operation.

Again as in the previous steps, CASCADE delete can be applied to remove all the dependent and dangling data.

Did you find this page helpful?
Start with GraphQL on Hasura for Free
  • ArrowBuild apps and APIs 10x faster
  • ArrowBuilt-in authorization and caching
  • Arrow8x more performant than hand-rolled APIs
Promo
footer illustration
Brand logo
© 2024 Hasura Inc. All rights reserved
Github
Titter
Discord
Facebook
Instagram
Youtube
Linkedin