GraphQL API (Datastore)- Field Level Auth Rule not working

Greetings,

in our project we try to define a proper GraphQL Model. Our goal is to use one model definition with different authentication types and rules for making requests via amplify datastore. We used amplifys GraphQL directives to annotate our model.

We defined the model like this:

type Entity @model
@auth(rules: [
    # Default owner access
    { allow: owner },

    # Admin group access
    { allow: groups, groups: ["Admin"] },

    # User
    { allow: groups, groups: ["User"], operations: [read] },

    # Everyone
    { allow: public, operations: [read] }
  ])
@key(name: "sort", fields: ["name"])
 {
    id: ID!
    owner: String
    name: String @auth(rules: [{ allow: owner, operations: [read] }, { allow: groups, groups: ["Admin"], operations: [read] }])
}

For granting non authenticated and authenticated users access to our api we implemented different authentication types by dynamically switching between "aws_appsync_authenticationType": "API_KEY" as the authentication method for unauthenticated users and "aws_appsync_authenticationType": "AMAZON_COGNITO_USER_POOLS" as the authentication method for authenticated users from cognito user pool.

Our auth rules should give owners and admins full access to CRUD operations for this type. Authenticated cognito users and unauthenticated users should only get read access to the model. For the field ‘name’ we want to define a specific behaviour, only the owners and users which belong to group ‘Admin’ should be able to read that field.

We assumed, if used field level auth rules are excluding any authentication for that specific field. So we had to grant explicit access for owners and admins.

Our amplify library version in our ReactJS project: "aws-amplify": "^3.3.13", "aws-amplify-react": "^4.2.17",

The expected behaviour was: Name field - Unauthenticated users should not be able to read the field ‘name’. Read access should only be granted to owners and group members of the cognito user pool group ‘Admin.’

The actual behaviour: Name field - Unauthenticated users and authenticated users, are both granted read access.

[dorontal]

@josefaidt I’ve been using Version 2 of Transformer in my report above, but I still see this issue with Version 2.

The schema with field-level @auth rule that I mention above still does not work. If I put my @auth rules on the Todo model, probably it won’t work either. That is, if you use this schema:

type Todo
  @model
  @auth(
    rules: [
      { allow: owner, operations: [read] }
      { allow: private, operations: [read] }
      { allow: public, provider: iam, operations: [read] }
    ]
  ) {
  id: ID!
  name: String!
  notes: String @auth(rules: [{ allow: owner, operations: [read] }])
}

then you’ll see that while the following query works:

query getTodo1($id: ID!) {
  getUser(id: $id) {
    name
  }
}

the following query throws an error with a message: “Not authorized to access notes on type String”:

query getTodo2($id: ID!) {
  getUser(id: $id) {
    name
    notes
  }
}

Note that this schema tries to take advantage of the new ‘deny-by-default’ – while model level @auth rules are more open, the field level @auth rule is supposed to supersede model-level, with ‘notes’ open to just the owner, read-only – but apparently it doesn’t allow the owner any read access right now.

[dorontal]

Sure, will do.