[RFC][v3] Authorization Rules in V3 #10237
Conversation
|
|
||
| Note, however, that cell-level authorization will not be supported by this system, since you define type (column) permissions and model (row) permissions independently. | ||
|
|
||
| 3. **Are any changes required to the NDC protocol?** |
There was a problem hiding this comment.
But if row and column permissions are disjoint, would you not want to push down the cell-level predicates? Or are you proposing that we redact data on the engine side.
That would be simpler but result in more network overhead.
I think it'd be worth spelling this out here.
| ```yaml | ||
| allowObjects: | ||
| relationship: | ||
| name: 'my_relationship' | ||
| relatedObjectAllowed: true | ||
| ``` |
There was a problem hiding this comment.
If this effectively autogenerates the permissions on the target model, what does it mean if one was to apply this attribute on the reverse relationship (ie the relationship from the target to the source)? Or if the target model already had permissions defined? It's unclear to me how this composes with everything else.
| authorizationRules: | ||
| # Rule 1: Allow users to see their own orders | ||
| - allowObjects: | ||
| fieldComparison: | ||
| fieldName: user_id | ||
| operator: _eq | ||
| value: | ||
| sessionVariable: x-hasura-user-id | ||
| condition: | ||
| equals: | ||
| left: sessionVariable: x-hasura-role | ||
| right: literal: user | ||
| # Rule 2: Disallow anyone except admins to see hidden orders | ||
| - denyObjects: | ||
| fieldComparison: | ||
| fieldName: is_hidden | ||
| operator: _eq | ||
| value: | ||
| literal: true | ||
| condition: | ||
| not: | ||
| equals: | ||
| left: sessionVariable: x-hasura-role | ||
| right: literal: admin |
There was a problem hiding this comment.
I hope we're planning on writing an expression evaluation system that evaluates and simplifies these expressions before pushing them down to the connectors? Otherwise this is going to get ugly and we'll be spitting very complex where clauses into databases.
There was a problem hiding this comment.
I think the idea is that (for now at least) expressions are evaluated in the engine only, since they only depend on the values of session variables. I agree that pushing down subexpressions is not a tractable plan.
| 1. **Will existing metadata continue to be work?** | ||
|
|
||
| Yes, existing metadata (using the `v1` version of permissions objects) will continue to work and trivially maps to the new system where the condition is an equality check on the `x-hasura-role` session variable. |
There was a problem hiding this comment.
I think we should consider letting the user pick which way they'd prefer to express their permissions, either this advanced system, or the existing role based system (which we just desugar into the the advanced system behind the scenes). This advanced system is very powerful, but also less obvious how to use it to recreate the simple use case and I contend that users who just need basic role-based permissions would find the old mechanism easier to author and understand.
To be clear, this doesn't mean just retaining support for the v1 ModelPermissions and TypePermissions, it means including both options on v2. Just retaining the old v1 types is not as good as it implicitly discourages their use because they are an "old version".
Description
Rendered