This document is to serve as an insight into the existing state of the GraphQL API part of Dgraph as it exists today. This is not to say that the GraphQL API is not usable for some use cases today, as it certainly is usable. What we intend to recognize with this document is that the GraphQL API is not as mature as it should be. Some of these things are oversights, some are design decisions that should be readdressed, and some are already accepted enhancements and fixes but have yet to be addressed or implemented.
Feature Requests, Bugs, and Limitations as of Feb. 2022
This document is complemented by the Dgraph Lambdas review link following. So lambda specific workarounds and limitations are intentionally not mentioned in this document. This document is for the GraphQL API as it’s own entity serving as a Public Facing API.
NOTE: EVERYTHING in this document should be important. But if anyone wants our (Jonathan and Anthony)’s opinion, here is order of importance.
Having a GraphQL with auth rules built in is an incredible feat. It would seem that this GraphQL API is then ready for public internet facing release. But there are some very important things that one should know to keep their data as protected as possible and realize that even with well thought out auth rules with the current implementation of auth logic some needed security logic is simply not available.
Many of these have been discussed extensively in other locations, so linking instead or rewriting novels here.
Update Rules not capable enough
Feature Request: Update After @auth Validation
This is the biggest problem. Right now you can prevent what data is allowed to be mutated, but not what it can be mutated to.
Without this if you have rules that only allow a user to edit their own posts, they could update their own post and change the author to some other author and then that author would own the post. This may be wanted, but there is no way to prevent it if this is not wanted.
If we have the following field level auth it would go towards fixing this, but to be a mature rule based auth system it HAS to have this post-update auth rules.
Field Level Authorization
How to achieve field level auth at the moment?
This would allow a client to see some fields or update some fields without needing to create linking-nodes which at the moment have other limitations (keep reading in Data Constraints)
Input Validation (cleanliness of data yup-like)
This would be similar to SQL Row Level Security (RLS) or the Check Constraint. Basically a way to ensure that data meets a format or pattern (maybe even graph pattern)
If we had Field Level Auth and more capable update post-update auth rules then we could most likely work around this, but it would be nice to have this security concern worked into the core of the system without needing additional work-arounds.
Optimizing GBAC rules
Separating Interface and Implementing Type Logic
Auth rules on interfaces cascade to the implementing type auth rules and get combined that implementing types must match ALL rules of the type and the interface, but sometimes that is not wanted, but rather the need is for the rules to be combined with OR logic instead.
Separating @auth out of Schema
Moving GraphQL Authorization to admin API
You should be able to edit the @auth of one type at a time, as keeping track of a large schema gets tedious.
Reusing Rules or Global Rules