Using @auth on individual fields?

Breaking this into it’s own topic, so here is the context:

From reading over the docs on @auth directive I understand that these directives can restrict access to the nodes themselves by using JWT properties to check for user roles, or matching graph fields against those properties.

Please correct me if I am wrong, but from how I understand it so far: Once a user has access to a node then the user also has access to all of the fields of that node. If I have a node labeled person and I want to restrict a specific property on that node such as a SSN, while allowing other properties such as the name and age, there is not a native @auth directive to do that at this time.

I am thinking that there is a way to control access to fields like this if instead of it living as a field it lives as a related node. query { person { name hasSSN { SSN } } } I could then control the hasSSN type with it’s own @auth directives.

The following statement from the docs has intrigued me.

In general, an auth rule should select a field that’s expected to exist at the inner most field, often that’s the ID or @id field. Auth rules are run in a mode that requires all fields in the rule to find a value in order to succeed. - The @auth directive

My initial thinking was that the inner fields in a rule would give access to those fields or restrict access to those fields, but that is not the case. If I understand this right this can be used to control access by looking for a field that would only exist if the user has access to the item. Not based upon a value of the field, but solely if it exists or not. If the rule in the example in the docs was changed to look for inner fields id, text and a node existed that did not have a text field then those nodes would be inaccessible. I am trying to think if this logic can somehow be used in a way to control access to fields, but I think the limitation I would run into is that this is only used for granting/restricting the whole node and not just the individual fields.

1 Like

Yeah, currently we don’t have auth to control access to individual fields.
We will try to include it in the 20.11 version.
All the fields are not required in order to succeed an auth rule, that is required only if you combined them using AND.
It depends on the rule that you have applied.


I’m trying to expose my backend to the wider-web, and want to disallow others from modifying the data.

type MyType @auth (
add: { rule: “{$user: { eq: “mrjn” } }”},
delete: { rule: “{$user: { eq: “mrjn” } }”},
update: { rule: “{$user: { eq: “mrjn” } }”}
id: String! @id
text: String! @search(by: [fulltext])
postedAt: DateTime @search @auth()

The 3 rules above allow the backend to be secure, so only I can modify the data. But, I also want to hide postedAt from being queried. How do I do that?


Any update on this?

It’s very hard to build something practical with Dgraph for me without @auth for individual fields…
E.g. imagine a user directory where some information like an email must not be visible publicly. What’s the recommended workaround currently for such usecases?

You can add do something like;:

type User {
  privateStuff: PrivateUserInfo!
  publicStuff: PublicUserInfo!

type PrivateUserInfo @auth(...)  {
   email: String!

type PublicUserInfo {
   whatever: String!

This of course can become very unhandy because you have to maintain several relationships.


Thanks so much! It looks a bit odd, but I guess that’d do while we are waiting for the support of this feature.

1 Like

@JatinDevDG @mrjn

Is there a reasonable eta for this one? The last update was ~9 months ago :slight_smile:

Hi @CosmicPangolin1 ,this feature will be available in 21.07 release.

1 Like

@JatinDevDG what is the estimated date for that release ? Is there a release schedule somewhere?

EDIT: Oh, I get it, I think 21.07 would be July this year right ?
I was really hoping for this to be coming out in 21.03 release.

Hi @sambhav-gore , sorry we had other priority items for 21.03 and not able to include this feature.
But that is included in our plan for 21.07 and yes,that will be released in July this year. So, you have to wait a bit more for it.

We are following calender versioning , you can read more about it here [Calender versioning] .(Why there would be no Dgraph 2.0: Goodbye Semantic Versioning - Dgraph Blog)

I’d integrate it with a “for” and “without” property like there is the “and” and “or” property in auth(…).
In there you could define all your fields you want to export or hide and then also the actual rule for those fields.

1 Like