Unnecessary headers expected

[webdeb]

Imagine email-subscriptions permissions for an anonymous-role are set to this:

(simplified)

  insert: {}
  update: { secret: "x-hasura-secret"} (got-from-email)

By requiring x-hasura-secret in update, I get an error, when trying to insert, which should't require the x-hasura-secret header.

"x-hasura-secret" header is expected but not found

Is this a bug, or a feature?
Thanks

[webdeb]

The funny thing is, that if I pass "something" the error disappears, but stills requires to put there even an empty string or so.

Btw. I found it very unpleasant to read the code, not because its haskell, which I do not have any experience with, but just because the naming conventions are so cryptic. I feel, that my brain needs a lot of energy to first understand the variables acronyms, before it can eventually dive into the logic

[0x777]

The update permission's filter condition has to be applied during an insert when on_conflict is used, something along the lines of ON CONFLICT ... SET ... WHEN <update-condition>.

Currently the server blindly tries to check for the existence of session variables in both insert's check expression and update's filter condition during an insert operation. This is a bug, the server should do the validation based on the structure of the query (i.e, update permission's session variables should only be checked for if on_conflict is used). I have a work in progress PR to fix this problem but it depends on #3598.

Related to #14

[aaronhayes]

Seems like this is the same issue I'm having, so just wanted to record my use-case without creating a new issue...

When using column presets from session variables, each header must be set. Even if the underlying field is nullable.

{
  "errors": [
    {
      "extensions": {
        "path": "$",
        "code": "not-found"
      },
      "message": "\"x-hasura-organisation-id\" header is expected but not found"
    }
  ]
}

[webdeb]

@0x777 any news on this?

Right now I got an even more strange error, as I tried to use Authorization + x-hasura-custom-header
it even did't recognized the header I've send. I guess the authorization overrides all existing headers.

[webdeb]

I was expecting, that hasura will take the default authorization-required headers like user-id and roles from the JWT, but also allow other headers from the request to be additionally provided.

IMHO hasura should take all x-hasura-* headers from JWT and assign all other "x-hasura-*" headers excluding the ones, which are already passed through the JWT, like its already possible with the x-hasura-role header