fix: Restrict write access to flows.data column via GraphQL API
#2488
Conversation
DafyddLlyr
changed the title
flows.data column
|
🤖 Hasura Change Summary compared a subset of table metadata including permissions: Updated Tables (1)
|
| const { client: $client } = getClient(); | ||
| const response = await $client.request<UpdateFlow>( | ||
|
|
||
| // XXX: This is using the API Hasura role |
There was a problem hiding this comment.
Let me know if a comment is not good enough here!
Alternatives considered are -
- Attempt a mutation before
UpdateFlowwhich we know user has permission for (e.g. setflow_slug=flow_slug). If this works we know user should be allowed to updateflow.data - Manually query permission (e.g. check join of userId → team_members → teamId → flowId). The tricky thing about a manual check is that this logic will always have to be updated alongside our permission and roles model.
For now, we're checking if the user is a platformAdmin via middleware and then executing this mutation. This is totally fine I think - I just wanted to leave a cautionary note behind.
There was a problem hiding this comment.
Agree with your decision/approach here ➕ thanks for explaining alternatives
|
Removed vultr server and associated DNS entries |
DafyddLlyr
changed the title
flows.data columnflows.data column via GraphQL API
| const { client: $client } = getClient(); | ||
| const response = await $client.request<UpdateFlow>( | ||
|
|
||
| // XXX: This is using the API Hasura role |
There was a problem hiding this comment.
Agree with your decision/approach here ➕ thanks for explaining alternatives
| replace: z | ||
| .string() | ||
| .optional() | ||
| .transform((val) => val && DOMPurify.sanitize(val)), |
There was a problem hiding this comment.
Thanks for catching this sanitation step too 👍
What does this PR do?
flows.datacolumn for all user rolesContext
Follow on from #2483 & #2484
I was hoping for a slightly simpler solution of relying on Hasura's backend-only permissions but this is just per-table, not per-column.
We should probably extend this approach to similar columns such as
global_settings.footer_contentandflows.settings. It might be best to follow the pattern of Editor → API → Hasura for these operations where we require sanitation before writing to the DB. Let's discuss this at the dev call!