You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Since we have many different types of users on our system and the users have different needs and most importantly different permissions, a one schema fits all approach is very hard to accomplish. A simple example are the roles of an analyst and a normal user. The normal user should only be able to see her/his data (enforced row level security) and the data analyst should see all the uses data.
Describe the solution you'd like
It would be great if it was possible to include a "role" key into the JWT that decides on which version of schema is used. The different versions of the could be differentiated ether by putting them into different folders oder appending the role name to the cube names.
Describe alternatives you've considered
I'm currently working around this by using complicated where clauses in my cubes.
Additional context
none
The text was updated successfully, but these errors were encountered:
Hey @davemaier ! Cube.js schema has a concept of context https://cube.dev/docs/context#top which isn't properly exposed yet. These contexts can be bound to the roles in order to provide RBAC. Let's use this issue to track this context and related APIs implementation.
hi @paveltiunov, I'm curious if any progress has been made on an RBAC model. right now the choices for enforcing permissions seem to be:
Rely on the database, e.g. PG's row-level-security and roles (probably using multiple connections)
Modify the query at run-time to by adding filters to limit rows, removing dimensions/measure to limit columns etc.
The first option would likely be secure enough but doesn't allow the app/UI to properly reflect permissions and the latter requires a lot of manual work to build an entire authz on top of Cube
Is your feature request related to a problem? Please describe.
Since we have many different types of users on our system and the users have different needs and most importantly different permissions, a one schema fits all approach is very hard to accomplish. A simple example are the roles of an analyst and a normal user. The normal user should only be able to see her/his data (enforced row level security) and the data analyst should see all the uses data.
Describe the solution you'd like
It would be great if it was possible to include a "role" key into the JWT that decides on which version of schema is used. The different versions of the could be differentiated ether by putting them into different folders oder appending the role name to the cube names.
Describe alternatives you've considered
I'm currently working around this by using complicated where clauses in my cubes.
Additional context
none
The text was updated successfully, but these errors were encountered: