Action handler - Do we do JWT auth in there?

[MelMacaluso]

Hi there

I may be incurring in an anti-pattern if so I would like to pick it up early.

The way I am validating data at the moment with actions is as follows:

1. Frontend (next.js) sends a grapqhl (react-apollo's useMutation hook) mutation from a form
2. It trigger an action I created in the hasura console
3. Such action calls my webhook endpoint handler (also in next.js, in this case in its backend API routes)
4. Made a middleware that checks for the action's secret and validates it
5. I then perform, within the handler by collecting the req.body.input parameters and the x-hasura-user-id from the headers, another grapqhl mutation (after successful validation) towards my main project's /graphql endpoint with the x-hasura-admin-secret header too.
6. The way the above query is made is by calling a mutation (dynamically created by hasura) such as

{
    update_client_data(
      _set: {
        example: $example
      }
      where: { user_id: { _eq: $user_id } }
    ) {
      affected_rows
    }
  }

My main questions are:

1. Is that the right flow in general
2. If it is should I still be using the X-Hasura-Admin-Secret
3. and if so is that the right way to write to the db finding the user with the where clause?
4. if not I thought about sending the user's access token to the endpoint handler and then putting it in the header with a bearer token so doing jwt validation (and the where can be empty as it will target just that field)
5. did I do something horribly wrong? everything was kind of deduced by the examples on validations provided by Hasura's github (the coupon one).

Thanks!

[quantumlicht]

If user_id is a primary key you could also use the update_client_data_by_pk (note the by_pk)`, so that you don't need the where clause.

4. raises an interesting question. I guess your application code has to decide what is the appropriate behavior. If your backend is making a request "on behalf" of the client, this usually means the client is not allowed to perform this request themselves.

An example I can give you is for example changing a field that needs to be validated by a computation. We would not want a user to bypass the validation.

If you end up having to forward the clients token to the hasura request you are making from the server, that probably means the client could make the request themselves.

The hasura permission engine is quite powerful, so it's a good idea to use it whenever possible. So far, I am using actions when I cannot leverage it.