Inner read (selections) authorization behavior

[anasbarg]

Inner read (selections) authorization behavior

Pragmafile: https://gist.github.com/anasbarg/f5617d17e45e35488689408322e14a16

Problem

I'm trying to run this query against the above Pragmafile:

query ReadBusiness {
  Business {
    read(username: "test") {
      username
      name {
        ar
        en
      }
      name1: name {
        ar
      }
    }
  }
}

and I'm getting the following result:

{
  "errors": [
    {
      "message": "No `allow` rule exists that allows `READ` operations on `Localized`"
    },
    {
      "message": "No `allow` rule exists that allows `READ` operations on `Localized`"
    },
    {
      "message": "No `allow` rule exists that allows `READ` operations on `Localized`"
    },
    {
      "message": "No `allow` rule exists that allows `READ` operations on `Localized`"
    },
    {
      "message": "No `allow` rule exists that allows `READ` operations on `Localized`"
    }
  ]
}

Expected

• Not to return any errors
• Even if an error must be returned, it shouldn't be duplicated as above. The problem here might be that the authorizer is checking the children selections (inner read ops) even if the parent selection (inner read op) is rejected; short circuiting on children will solve the problem.

[m-tabaza]

The errors are returned because the PermissionTree doesn't return rules that reference fields for inner-read operations (selections.) Adding these rules to the return of PermissionTree#innerReadRules should solve the issue.

[anasbarg]

This will be solved #76

[anasbarg]

This will be solved #76

Still, we need to fix the redundant error messages by short-circuiting on children of a failed parent in the authorizer.

[anasbarg]

This will be solved #76

Still, we need to fix the redundant error messages by short-circuiting on children of a failed parent in the authorizer.

I created a issue #80 for this one since it's of a different priority.