Unexpected behavior with @auth rules when using fragments and @cascade

Issues GraphQL
, , ,
10

Hi @christian-roggia, the fix for this issue has been merged in master with this PR: fix(GraphQL): Fix fragment expansion in auth queries (GRAPHQL-1030) by abhimanyusinghgaur 路 Pull Request #7467 路 dgraph-io/dgraph 路 GitHub

I have verified that it works with the steps you had shared along with the schema and sample data.
Thanks for the nice set of steps in that README :slight_smile:

There are a few things to note:

  • Previously, auth queries didn鈥檛 used to expand fragments within them. Now they do. This was one part of the bug.
  • Also previously, auth queries always used to automatically apply @cascade irrespective of whether there was one already in auth rules or not. Now, they check that if there is @cascade already present in the auth rule, then they don鈥檛 apply it. This was the other part of the bug.
  • @cascade doesn鈥檛 work in an intuitive manner on abstract (Interface/Union) fields, where there are multiple fragments with different type conditions and any one of those fragments has a field that exclusively belongs to that type. The thing to note here is that @cascade works, but not in an intuitive manner. So, in such cases it is always a good idea to have only one kind of fragment on that abstract field, if you also want @cascade to work in an intuitive manner.

Thanks

2 Likes