Graphql-engine: why is x-hasura-default-role is prefered over x-hasura-role

[ifdotpy]

Hi! Thank you for your awesome work.

I have an issue with jwt. While using this _HASURA CLAIMS_:

{ "x-hasura-default-role": "anonymous", "x-hasura-allowed-roles": [ "user", "anonymous", "admin", "institution-admin" ], "x-hasura-role": "user", "x-hasura-user-id": "rglCjqnVAKbBx0Q7jke73blCKmu1" }

Hasura identifies request sender as anonymous

When changed to this _HASURA CLAIMS_:
{ "x-hasura-default-role": "user", "x-hasura-allowed-roles": [ "user", "anonymous", "admin", "institution-admin" ], "x-hasura-role": "user", "x-hasura-user-id": "rglCjqnVAKbBx0Q7jke73blCKmu1" }

Hasura identifies request sender as user

Why can this be happening?

[0x777]

x-hasura-role has to be sent with the http request. It is not expected to be part of the JWT's hasura claims and as such it is ignored. The x-hasura-role sent with the request is checked to see if it is part of the x-hasura-allowed-roles and if yes, the request is executed as that role. In case the x-hasura-role is missing, the x-hasura-default-role from the JWT is used.

[dohomi]

In my opinion / besides the confusion I had just now, the developer needs to verify the HTTP header again - I thought this would be done directly in the JSON token already. It leads to slightly more written code - the client side needs to attach the header, the server side needs to validate if the Authentication + x-hasura-role is actually still valid
UPDATE:
Is this not a potential security issue? if the generated token includes the hasura-role, thats not readable for any user. But to attach a request header as simple as x-hasura-role:"admin" could be fairly manipulated and as far as I see it won't be verified

[ifdotpy]

@dohomi Initially I also thought it is a security issue. But then realized that auth server should return correct role list (x-hasura-allowed-roles). Which means that the roles in the list are the only roles that can be put into x-hasura-role header.

[dohomi]

yes.. I was a bit slow in my head and initially thought that allowed-roles should be same across all created JWT tokens. But now I prepare the JWT on the server that the default-role and allowed-roles are directly connected to the user and the security flaw I had in mind before is gone. A user only has allowed-roles:["user"] while an admin potentially could verify himself as user-role:["admin","user","manager"] and set the default-role:"admin"

[ifdotpy]

@dohomi I thought same when created the issue.

[galipmedia]

This has really thrown me. I have my headers set in a boot file that gets setup once and checks if there is a jwt or not which is fine because that is either there or not. But say I want a 'user' to be able to see all his own details based on his x-hasura-id, but i also want him to be able to see as 'public' all the other users usernames and avatars he cannot, he only sees his own in the list. It means I will have to carefully chain all my queries and for each one set some state of x-user-role and inject it in the headers, that seems like a nightmare. Surely your average Joe using vue-apollo or something is not going to want to do this. Does anyone know a better way? Is it bad practice to have 2 apollos setup, one for each user role ?

[galipmedia]

It just occurred to me that I have to use a view in the database and give it different permissions, with just the fields I want them to see and allow public and user to view that table too.