Feature Request: Update After @auth Validation

[jdgamble555 (Jonathan Gamble)]

Why this is VERY important and easy to fix…

Right now, there is no way to add any external application to Dgraph’s GraphQl. Only Dgraph can do that, so we are locked-in without any way to secure mutations unless we want to re-write every single mutation in a custom-mutation. This means for any practical application, regular mutations are worthless.

This is far from trivial and concerns Backend Security.

Some more links I found:

GraphQL Update Endpoint @auth Feedback

Tell me if there is a better place to put this feedback, but I was just going through the docs for @auth in GraphQL mode and read: Currently, Dgraph evaluates update rules before the mutation. Our auth support is still in beta and we may extend this for example to make the update rule an invariant of the mutation, or enforce pre and post conditions, or even allow custom logic to validate the update data. I’m not sure that this is the latest status as this is very “in-development” at the mome…

How to reference the authenticated user with the entity that is going to be created

FYI: https://dgraph.io/docs/graphql/authorization/mutations/#add Rules for add authorization state that the rule must hold of nodes created by the mutation data once committed to the database. Delete rules filter the nodes that can be deleted. A user can only ever delete a subset of the nodes that the delete rules allow. Currently, Dgraph evaluates update rules before the mutation. How Dgraph handles update rules would allow a user to take a Help and assign it to a different Us…

More Problems this solves:

• Null Field Problem
• Require a Field Problem
• Field Level Auth
• Role Based Auth from Database
• General Field Validation

I think most people believe @auth works like this out of the box. There are many more problems this could solve, but very little code for very big reward.

Simple Fix:

Edit auth.go!

• An add mutation is evaluated by data that WILL be in the database…
• An update mutation is evaluated by data that is already IN the database

Simple add a new rule handle update-after or afterUpdate or whatever name that…

• An updateAfter is evaluated by data that WILL be in the database (just using the add validation)

These functions are already written, just add a few new lines. If I were a go programmer, I would do a ping request myself.

This is very important and will solve many problems.

There is potentially another option where any incoming data added by an update mutation is evaluated by BOTH @auth add rules, and @auth update rules, but I feel there could be some conflict here.

Either way, this keeps the database consistent, and is VERY LITTLE WORK with BIG REWARDS for us users!

Thanks,

J