Session variables in Websockets

[tarwich]

You guys have helped me a ton to get my application up and working smoothly. Now that I'm transitioning to subscriptions I'm hitting some hurdles.

I'm trying to use different roles for different subscriptions. My AuthToken has X-Hasura-Allowed-Roles to include all the roles I'm trying to access. My goal is to call useSubscription (Apollo) with X-Hasura-Role: 'creator' on one subscription and X-Hasura-Role: 'user' on another.

I've succeeded in transmitting the roles as part of the WebSocket payload. However, it seems Hasura is ignoring them. When using HTTP requests, I'm able to set them in the request header as mentioned in the documentation. However, it apparently doesn't work as part of a WebSocket payload.

{
    "id": "2",
    "type": "start",
    "payload":
    {
        "variables": {},
        "extensions": {},
        "operationName": "CreatorCourses",
        "query": "[REDACTED]",
        "x-hasura-role": "creator",
        "Headers":
        {
            "x-hasura-role": "creator"
        }
    }
}

Is this supposed to work? Will it ever be supposed to work? Am I thinking about this totally wrong? Thanks again for all the help!

This is in Hasura 2.0.9

[tarwich]

Well... after sleeping on it, I'm starting to think I AM doing things wrong. What I was doing was making each request with the appropriate role for the request. If a user was accessing their profile, I would make the request with USER_ROLE, but if they were creating a course, I would call with the COURSE_ROLE. This was protected by a user not having CREATOR_ROLE in their ALLOWED_ROLES, so they couldn't get around the system.

Perhaps I should make the token (and every subsequent request) with the highest available role instead. That would fix a lot of problems, and make most things work (including subscriptions). However, at that point I'm not sure what the purpose is of X-Hasura-Allowed-Roles.

[tarwich]

We're using the highest role now. It introduces a lot of complications, but it works, and it allows role changes to be reflected quickly on the client. However, it falls to pieces with 2-minute refresh tokens. When a token expires, Apollo just gives up instead of sending another connection header in the stream. This seems to be a continued case for allowing session variables to be set in the stream. What do you think?