Handling multiple roles on the graphql client (possibly in the same query)

• In an application, one user often have multi roles at the same time, at a screen. Let’s say, in a blog application, both editor and author could edit a post. So if a user is both an editor and an author, how to authenticate with hasura then ? In this case, hasura should support multi-roles in headers: x-hasura-roles instead of x-hasura-role. Else how do you decide which role the user should use ? Because all roles are equal and valid.

• What i mean by multi-roles query is that.

query {
table1 {
 field1
}
table2 {
 field2
}

Suppose that user has roles role1 for table1, and role2 for table2 . This is currently impossible to make above query.

• OK, what’s if a websocket connection is made by above query. Now the user’s role changed, what happen ? The websocket connection should not be recreated for that. Instead the subscription data should reflect the change after that.

And this is the second hard part to solve this problem (when roles change for a subscription query)

• Suggested implementation (per @coco98 ) The query now should look like this

query {
  asUser {
    someTable {...}
  }
  asManager {
    someTable {...}
  }
}

Note 2 : My proposed solution

In Console UI for permission setting, there must be ability to assign current permission to another roles in system (or creation new role). Only then that, Hasura could validate one role or array of roles query to resolve correct data to return.

[nolandg]

Inability to assign multiple roles for a user makes permissions much more work and more error prone. I find myself duplicating a lot of permissions, definitely not DRY design. We need to cascade permissions between roles.

Take for example a blog site. You have content editors, moderators, and admins. Their permissions naturally cascade. A moderator must have all permissions an editor has + more and an admin has all moderator perms + more. The only way I have found to do this with Hasura is to duplicate all the perms from editor over to moderator etc. But then if editor perms change, I have to manually cascade those changes to moderator and admin. It becomes a mess. I shouldn’t have to say that admins are able to view posts because that has already been accounted for in a “lesser” role.

If we could simply assign editor, moderator, and admin to a single user it would be so much more reliable.

[go4cas]

@shahidhk … my understanding of the current JWT role workflow is:

1. The token is decoded, and checked whether both x-hasura-default-role and x-hasura-allowed-roles are included
2. If both headers exist, it is checked whether the x-hasura-default-role is part of the roles defined in x-hasura-allowed-roles
3. If the x-hasura-role header is present, then this value is checked against the x-hasura-allowed-roles and it overrides x-hasura-default-role as the role to use
4. The role (either x-hasura-default-role or x-hasura-role) is then checked against the role defined on the permissions on the table(s) in the graphql query.

My suggestion (and it’s really a question whether this is doable or not): The x-hasura-default-role becomes optional, and the following is implemented:

• If both x-hasura-default-role AND x-hasura-role are present, use the workflow as described above
• If either x-hasura-default-role OR x-hasura-role is present, use whichever is available, and use the workflow as described above
• If NEITHER x-hasura-default-role AND x-hasura-role are present, then simply use the x-hasura-allowed-roles to check against the table(s) in the graphql query.

What do you think?

This way, the role system will be backwards compatible, and you give developers an option on how to implement roles coming from their client apps.