[sadturnip]

I tried Hasura in the past and unfortunately found it unsuitable for our auth requirements. There is no way currently to hook into their authorization system, you get extremely basic RBAC and if that isn't good enough for you too bad.

For example we currently are required to talk to some external auth services (depends on the customer) and fetch the users permissions based on that, (e.g. user can READ notes, and WRITE notes but not delete NOTES). At the time we had an extremely simple express middleware that handled this.

Also the entire idea that i need another GraphQL or rest server to do any sort of custom validation/custom actions made me do a double take and more or less killed any interest to me.

We ended up using NestJS with their GraphQL tooling and objection.js and never looked back. Ironically the adoption of the GraphQL version of our API compared to Rest is almost 0.

[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.