[tango12]

Hasura's authz is whatever authz you can derive from the data within your database or from the claims embedded in the authn token. If you have a table that contains the claims for each user, then you can reference that in the authz rule for any other table/view/function. READ notes if user.is_note_reader = true.

We're working on making it easy to integrate resource claims and rule engines that are external as well (make an IO call instead of embedding the rule in the SQL query itself). The good news is that it is possible to do at the Hasura layer because Hasura owns the RBAC so we'll get to it soon enough :)

Over the last few months, we've seen users flip from their custom GraphQL servers to using Hasura because of the reduction in code/maintenance that Hasura brings for their use-cases. Especially when you have a large number of tables. Being able to manage authorization rules at a "type" level instead of a "resolver" level also makes things convenient.

We've also started work on making it easy to integrate REST APIs for custom logic (esp writes) which also helps skip a bunch of GraphQL/authz boilerplate: https://blog.hasura.io/introducing-actions/

[sadturnip]

Unfortunately we do not have these claims defined in our auth token or the datasource hasura is attached to. We have an external session cache service in Redis. If the user isn't cached we need to hit an internal API to attempt to fetch this information for us and return it to us. No user information is stored in our auth token/database.

Actions look painful, i don't want to write and maintain microservices just to do simple actions. I just want to be able to write code and handle the hook around the function. Also from the link it only seems like actions occur AFTER something happens, i need the ability to run before changes are persisted.