Feature Request - field level @auth rules

[jdgamble555]

https://discuss.dgraph.io/t/how-to-achieve-field-level-auth-at-the-moment/13069 https://discuss.dgraph.io/t/using-auth-on-individual-fields/7208

Currently there is no way to secure a field differently than the entire type.

I have seen around 5 people leave DGraph due to this missing feature alone.

Example 1

Let's say I have:

type Post @auth(...) {
  id: ID!
  title: String!
  votes: [User]
  ...
}

I can use Auth Rules to prevent users from adding and updating the type. But what if I want to allow users to edit a certain field, and only a certain field.

If a user votes, they need to add a connection in the votes type. They should not have access to the other fields.

Example 2

The opposite example is preventing a user from editing a field in a post:

type User @auth(...) {
  id: ID!
  username: String!
  role: Role!
  ...
}

Let's say the role is User. I should not allow a regular user to update their own role to Admin.

---

The theoretical fix would be to have something like this:

type Post @auth(...) {
  id: ID!
  votes: [User] @auth(... some field based auth rule here)
  ...
}

Security makes and breaks DGraph for a lot of users, and this is one of the important ones.

J

[rderbier]

From community:

Just an additional note on the necessity of field level auth:

An important use case for this is the ability to add comments to a post where the post has a field:

type Post {
   ...
   comments: [Comment] 
}

If any user has update access to the post, the user is able to modify the whole post. Otherwise they are unable to add a comment to the post. Seeing as "Social media sites, Content Management Systems, and Ecommerce stores" are highlighted in the first page of the docs as use cases, it seems counterintuitive that this functionality isn't possible without some hacky workaround, that isn't consistent with the use of the @auth directive, when all of these use cases have this functionality as ubiquitously fundamental to their design.

The @auth directive could prove as an extremely powerful tool in allowing end users to access data from dgraph, and considering update-after-auth and field level updates are mentioned frequently, it seems an upheaval of the @auth directive is likely a necessity. Not ignoring of course the fact that the existing interface is clunky at best, and could be prone to errors in development.

The redevelopment of this is also beneficial, fiscally, for dgraph cloud, as if the @auth directive could be relied upon for all user access auth, it will reduce the need for purpose built API interfaces to be built on top of dgraph, allowing total public access to the dgraph DB. This in turn would increase the number requests made to the server...

just a thought.