@brene @Ashish-Nanda @undefobj @SwaySway @amhinson @manueliglesias @sammartinez @yuth @iartemiev @elorzafe @UnleashedMind

DataStore @auth directive combinations

Like I said in my previous comment, I am currently working on a React Native app which utilizes the great power of DataStore to allow users to use the app while being offline. With that being said, just like a lot of other people I am running into issues when trying to use DataStore in conjunction with the @auth directive.

When I first read the Amplify docs, I was under the impression that almost all the documented directives would work in conjunction with the DataStore, but unfortunately this doesn’t seem to be the case. (Could we maybe add a separate directives section to the DataStore documentation?)

Problems start to arise (in the form of failing subscriptions) whenever you try and limit operations, or try and layer multiple different authentication methods.

In an effort to help out the AWS Amplify team, and to speed up fixes for these use cases, I tested a variation of different @auth rules in combination with the DataStore. The outcome can be found below.

For the sake of the app we’re working on, which we plan on releasing very soon (fingers crossed), and everyone else wanting to leverage the power of DataStore but requires slightly more complex @auth directive usage beyond a single user or multiple users that have full access to every operation, hopefully this helps even a little bit.

Extra context

Library versions:

• @aws-amplify/datastore: 2.2.3
• @aws-amplify/cli: 4.21.3

These steps were performed with/before each test:

1. Log users out of iOS and Android simulators
2. Modify schema
3. Run amplify push
4. Run amplify codegen models
5. Reload devices
6. Log in with 2 different users
7. Observe model on DataStore
8. Try creating/updating new model from both devices

If applicable to schema, the following steps were also performed:

• Try creating/updating new model from AppSync console (logged in as one of the users)
• Try creating/updating new model from AppSync console (logged in as a user part of the “Admin” group)
• Try creating/updating new model from Lambda (IAM)

Schema’s

Only 5/14 schema’s work as expected. I am particularly interested in limiting operations for an owner, while allowing the owner to receive updates for all operations, and having IAM authentication in combination with the owner rule. I was unable to get any subscriptions to work when layering an IAM auth rule on top of an owner rule.

• Schema 1 (works) { allow: owner }
• Schema 2 { allow: owner, operations: [create, update, delete] }
• Schema 3 { allow: owner, operations: [create, update, delete] } { allow: private, operations: [read] }
• Schema 4 { allow: owner } { allow: private, provider: iam }
• Schema 5 (works) { allow: owner } { allow: groups, groups: [“Admin”] }
• Schema 6 { allow: owner, operations: [create, read] } { allow: groups, groups: [“Admin”] }
• Schema 7 { allow: owner, operations: [create, read, update] } { allow: groups, groups: [“Admin”] }
• Schema 8 (works) { allow: owner, identityClaim: “custom:user_id” } { allow: groups, groups: [“Admin”] }
• Schema 9 { allow: owner, identityClaim: “custom:user_id”, operations: [create, read, update] } { allow: groups, groups: [“Admin”] }
• Schema 10 { allow: owner } { allow: private, provider: iam } { allow: groups, groups: [“Admin”] }
• Schema 11 { allow: owner } { allow: owner, ownerField: “editors”, operations: [update, read] }
• Schema 12 { allow: owner, identityClaim: “custom:user_id” } { allow: groups, groups: [“Admin”] }
• Schema 13 (works) { allow: groups, groups: [“Member”], operations: [read] } { allow: groups, groups: [“Admin”] }
• Schema 14 (works) subscriptions: { level: public } { allow: owner, operations: [create, read] } { allow: groups, groups: [“Admin”] }

Schema 1 (works) #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent(owner: String!): SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent(owner: String!): SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent(owner: String!): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema works as expected.

Schema 2 #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner, operations: [create, update, delete] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent: SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent: SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent: SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema doesn’t work as expected. Subscriptions fail, and result in the following warnings/errors:

[WARN] 38:14.669 DataStore - Connection failed: {"errors":[{"message":"Validation error of type UnknownArgument: Unknown field argument owner @ 'onDeleteSharedContent'"}]}
[WARN] 38:14.756 DataStore - Connection failed: {"errors":[{"message":"Validation error of type UnknownArgument: Unknown field argument owner @ 'onUpdateSharedContent'"}]}
[WARN] 38:14.802 DataStore - Connection failed: {"errors":[{"message":"Validation error of type UnknownArgument: Unknown field argument owner @ 'onCreateSharedContent'"}]}

Schema 3 #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner, operations: [create, update, delete] },
    { allow: private, operations: [read] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent: SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent: SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent: SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema doesn’t work as expected. Subscriptions fail, and result in the following warnings/errors:

[WARN] 53:08.331 DataStore - Connection failed: {"errors":[{"message":"Validation error of type UnknownArgument: Unknown field argument owner @ 'onCreateSharedContent'"}]}
[WARN] 53:08.358 DataStore - Connection failed: {"errors":[{"message":"Validation error of type UnknownArgument: Unknown field argument owner @ 'onDeleteSharedContent'"}]}
[WARN] 53:08.413 DataStore - Connection failed: {"errors":[{"message":"Validation error of type UnknownArgument: Unknown field argument owner @ 'onUpdateSharedContent'"}]}

Schema 4 #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner },
    { allow: private, provider: iam }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent(owner: String!): SharedContent @aws_subscribe(mutations: ["createSharedContent"]) @aws_iam @aws_cognito_user_pools
onUpdateSharedContent(owner: String!): SharedContent @aws_subscribe(mutations: ["updateSharedContent"]) @aws_iam @aws_cognito_user_pools
onDeleteSharedContent(owner: String!): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"]) @aws_iam @aws_cognito_user_pools

This schema doesn’t work as expected. Subscriptions fail, and result in the following warnings/errors:

[WARN] 26:54.58 DataStore - Connection failed: {"errors":[{"message":"Validation error of type MissingFieldArgument: Missing field argument owner @ 'onDeleteSharedContent'"}]}
[WARN] 26:54.97 DataStore - Connection failed: {"errors":[{"message":"Validation error of type MissingFieldArgument: Missing field argument owner @ 'onCreateSharedContent'"}]}
[WARN] 26:54.156 DataStore - Connection failed: {"errors":[{"message":"Validation error of type MissingFieldArgument: Missing field argument owner @ 'onUpdateSharedContent'"}]}

Schema 5 (works) #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema works as expected.

Schema 6 #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner, operations: [create, read] },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema doesn’t work as expected. The onDeleteSharedContent and onUpdateSharedContent subscriptions fail. The result is the following warnings/errors:

[WARN] 33:56.520 DataStore - Connection failed: {"errors":[{"errorType":"Unauthorized","message":"Not Authorized to access onDeleteSharedContent on type Subscription"}]}
[WARN] 33:56.553 DataStore - Connection failed: {"errors":[{"errorType":"Unauthorized","message":"Not Authorized to access onUpdateSharedContent on type Subscription"}]}

I guess in this case, the subscriptions failing could be seen as “intended” since the owner doesn’t have the update and delete operations, but I feel like a more common use case would be that the owner can’t run the update and delete mutations, but still has access to the onUpdate and onDelete subscriptions. Maybe introducing something like a “listen” operation, which I saw in a different GitHub issue would be a way to control this behaviour separately?

Schema 7 #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner, operations: [create, read, update] },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema doesn’t work as expected. The onDeleteSharedContent subscription fails, and result in the following warnings/errors:

[WARN] 51:55.649 DataStore - Connection failed: {"errors":[{"errorType":"Unauthorized","message":"Not Authorized to access onDeleteSharedContent on type Subscription"}]}

Same as in Schema 6, the subscription failing could be seen as “intended” since the owner doesn’t have the delete operation, but I feel like a more common use case would be that the owner can’t run the delete mutation, but still has access to the onDelete subscriptions. Maybe introducing something like a “listen” operation, which I saw in a different GitHub issue would be a way to control this behaviour separately?

Schema 8 (works) #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner, identityClaim: "custom:user_id" },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Requires you to pass an idToken instead of an accessToken in Amplify configure:

Amplify.configure({
  ...awsConfig,
  graphql_headers: async () => {
    try {
      const session = await Auth.currentSession();
      const token = session.idToken.jwtToken;

      return { Authorization: token };
    } catch {}
  },
});

Generates the following subscriptions:

onCreateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema works as expected.

Schema 9 #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner, identityClaim: "custom:user_id", operations: [create, read, update] },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Requires you to pass an idToken instead of an accessToken in Amplify configure:

Amplify.configure({
  ...awsConfig,
  graphql_headers: async () => {
    try {
      const session = await Auth.currentSession();
      const token = session.idToken.jwtToken;

      return { Authorization: token };
    } catch {}
  },
});

Generates the following subscriptions:

onCreateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema doesn’t work as expected. The onDeleteSharedContent subscription fails, and result in the following warnings/errors:

[WARN] 37:22.453 DataStore - Connection failed: {"errors":[{"errorType":"Unauthorized","message":"Not Authorized to access onDeleteSharedContent on type Subscription"}]}

Same as in Schema 6 & 7, the subscription failing could be seen as “intended” since the owner doesn’t have the delete operation, but I feel like a more common use case would be that the owner can’t run the delete mutation, but still has access to the onDelete subscriptions. Maybe introducing something like a “listen” operation, which I saw in a different GitHub issue would be a way to control this behaviour separately?

Schema 10 #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner },
    { allow: private, provider: iam },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["createSharedContent"]) @aws_iam @aws_cognito_user_pools
onUpdateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["updateSharedContent"]) @aws_iam @aws_cognito_user_pools
onDeleteSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"]) @aws_iam @aws_cognito_user_pools

This schema doesn’t work as expected. Subscriptions work, but users see other user’s content. Queries properly return only the owner’s content.

Schema 11 #

Similar to example from docs: https://docs.amplify.aws/cli/graphql-transformer/directives#multiple-authorization-rules

type SharedContent
  @model
  @auth(rules: [
    { allow: owner },
    { allow: owner, ownerField: "editors", operations: [update, read] }
  ])
{
  id: ID!
  content: String
  owner: String
  editors: [String]
}

Generates the following subscriptions:

onCreateSharedContent(owner: String!, editors: String!): SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent(owner: String!, editors: String!): SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent(owner: String!, editors: String!): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema doesn’t work as expected. Subscriptions fail, and result in the following warnings/errors:

[WARN] 17:46.494 DataStore - Connection failed: {"errors":[{"message":"Validation error of type MissingFieldArgument: Missing field argument owner @ 'onUpdateSharedContent'"}]}
[WARN] 17:46.579 DataStore - Connection failed: {"errors":[{"message":"Validation error of type MissingFieldArgument: Missing field argument editors @ 'onDeleteSharedContent'"}]}
[WARN] 17:46.627 DataStore - Connection failed: {"errors":[{"message":"Validation error of type MissingFieldArgument: Missing field argument editors @ 'onCreateSharedContent'"}]}

Schema 12 #

type SharedContent
  @model
  @auth(rules: [
    { allow: owner, identityClaim: "custom:user_id" },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent(owner: String): SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema doesn’t work as expected. Subscriptions fail, and result in the following warnings/errors:

[WARN] 15:09.631 DataStore - Connection failed: {"errors":[{"errorType":"Unauthorized","message":"Not Authorized to access onCreateSharedContent on type Subscription"}]}
[WARN] 15:09.700 DataStore - Connection failed: {"errors":[{"errorType":"Unauthorized","message":"Not Authorized to access onUpdateSharedContent on type Subscription"}]}
[WARN] 15:09.741 DataStore - Connection failed: {"errors":[{"errorType":"Unauthorized","message":"Not Authorized to access onDeleteSharedContent on type Subscription"}]}

Schema 13 (works) #

Based on recent fix: https://github.com/aws-amplify/amplify-cli/pull/4340

type SharedContent
  @model
  @auth(rules: [
    { allow: groups, groups: ["Member"], operations: [read] },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent: SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent: SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent: SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema works as expected, but the recent fix only seems relevant if you use group auth.

Schema 14 (works) #

type SharedContent
  @model(subscriptions: { level: public })
  @auth(rules: [
    { allow: owner, operations: [create, read] },
    { allow: groups, groups: ["Admin"] }
  ])
{
  id: ID!
  content: String
  owner: String
}

Generates the following subscriptions:

onCreateSharedContent: SharedContent @aws_subscribe(mutations: ["createSharedContent"])
onUpdateSharedContent: SharedContent @aws_subscribe(mutations: ["updateSharedContent"])
onDeleteSharedContent: SharedContent @aws_subscribe(mutations: ["deleteSharedContent"])

This schema works as expected, and is useful if you don’t care that your subscriptions are public.

Thank you @mdoesburg

I just want to post an update here to let you know that we are looking into this, thank you so much for the super thorough breakdown!

@chuckatc We’re actively working on this and expect a fix for this very soon. cc @yuth @elorzafe

@mauerbac Is there a plan or strategy in place to fix this issue? You mentioned here there’s at least an intention to solve this.

I would like to know if there’s an RFC for this. I’d love to know what’s the plan because that can help me get prepared for the fix.

I have already implemented a workaround (on my fork) that involves passing an Observable into the SyncEngine so that events can be tunneled into it. This is not necessarily an elegant or safe solution, but it’s simple and works. I’ve overcome all sync problems due to failing subscriptions and have been able to implement Multiple authorization rules and keep Offline Support.

Reopening cc @sammartinez @manueliglesias @iartemiev

I want to add some insight into a couple of issues here. Thanks to @mdoesburg for the heavy lifting in providing a multitude of scenarios. In this post, I’m going to focus on the Schemas closest to my use case.

---

GraphQL Validation Error

Schema#11 has 2 owners, owner: String and editors: [String]

  @auth(rules: [
    { allow: owner },
    { allow: owner, ownerField: "editors", operations: [update, read] }
  ])

When the DataStore subscribes to events, the messages thrown are GraphQL validation errors:

[WARN] 17:46.627 DataStore - Connection failed: {"errors":[{"message":"Validation error of type MissingFieldArgument: Missing field argument editors @ 'onCreateSharedContent'"}]}

The reason for this is the way the DataStore builds the GraphQL subscription. Looking at the DataStore code, it will iterate all items with the owner AuthStrategy, and select the last one.

https://github.com/aws-amplify/amplify-js/blob/main/packages/datastore/src/sync/processors/subscription.ts#L177-L188

		ownerAuthRules.forEach(ownerAuthRule => {
			const ownerValue = cognitoTokenPayload[ownerAuthRule.identityClaim];

			if (ownerValue) {
				result = {
					authMode: GRAPHQL_AUTH_MODE.AMAZON_COGNITO_USER_POOLS,
					isOwner: ownerAuthRule.areSubscriptionsPublic ? false : true,
					ownerField: ownerAuthRule.ownerField,
					ownerValue,
				};
			}
		});

The ownerAuthRules list is obtained from the generated schema src/models/schema. A plausible solution to this is changing the order of the rules.

This solves the GraphQL Validation Error since now the subscription statement (generated automatically by the DataStore) will compile. We can assume then, that all GQL Validation Errors are caused by the DataStore automatic generation.

---

Authentication Error

Schema#6 and others have a different type of error, it’s an authentication error. NOTE: I am not getting this error when testing on my side. My error is different (gql validation) BUT I’m going to ignore that for the purpose of completing this analysis. I am assuming the one provided by @mdoesburg.

  @auth(rules: [
    { allow: owner, operations: [create, read] },
    { allow: groups, groups: ["Admin"] }
  ])

[WARN] 33:56.520 DataStore - Connection failed: {"errors":[{"errorType":"Unauthorized","message":"Not Authorized to access onDeleteSharedContent on type Subscription"}]}

This means that the GQL generated by the DataStore is valid, but the authentication failed on the resolver. This is much less related to the DataStore. But, let’s point out that the DataStore generates a subscription statement that does not include the owner because the group AuthStrategy has prevalence.

To look further into this we need to look at the generated VTL amplify/backend/api/<yourapiname>/build/resolvers/Subscription.onUpdateSharedContent.res.vtl.

The first thing it’s going to check is the Static Group Authorization. If the user is an Admin or not.

  ## [Start] Static Group Authorization Checks **
  #set($isStaticGroupAuthorized = $util.defaultIfNull(
            $isStaticGroupAuthorized, false))
  ## Authorization rule: { allow: groups, groups: ["Admin"], groupClaim: "cognito:groups" } **
  #set( $userGroups = $util.defaultIfNull($ctx.identity.claims.get("cognito:groups"), []) )
  #set( $allowedGroups = ["Admin"] )
  #foreach( $userGroup in $userGroups )
    #if( $allowedGroups.contains($userGroup) )
      #set( $isStaticGroupAuthorized = true )
      #break
    #end
  #end
  ## [End] Static Group Authorization Checks **

It will then check the owner passed in the subscription against the username in the JWT.

  ## [Start] Owner Authorization Checks **
  #set( $isOwnerAuthorized = false )
  ## Authorization rule: { allow: owner, ownerField: "owner", identityClaim: "cognito:username" } **
  #set( $allowedOwners0 = $util.defaultIfNull($ctx.args.owner, null) )
  #set( $identityValue = $util.defaultIfNull($ctx.identity.claims.get("username"),
                        $util.defaultIfNull($ctx.identity.claims.get("cognito:username"), "___xamznone____")) )
  #if( $util.isList($allowedOwners0) )
    #foreach( $allowedOwner in $allowedOwners0 )
      #if( $allowedOwner == $identityValue )
        #set( $isOwnerAuthorized = true )
      #end
    #end
  #end
  #if( $util.isString($allowedOwners0) )
    #if( $allowedOwners0 == $identityValue )
      #set( $isOwnerAuthorized = true )
    #end
  #end
  ## [End] Owner Authorization Checks **

And finally fails if either of the checks above is successful.

  ## [Start] Throw if unauthorized **
  #if( !($isStaticGroupAuthorized == true || $isOwnerAuthorized == true) )
    $util.unauthorized()
  #end
  ## [End] Throw if unauthorized **

Based on the DataStore logic, no owner is passed in the subscription query, therefore the second check will always fail. Which leaves us back to the Static Group Auth. A possibility then is that the user is not part of the Admin group. Other that, I might be missing something.

I’m still getting an error if I use a custom ownerField in @auth decorator. Basically, with the following GraphQL schema it all works fine - default owner field:

type User @model @auth(rules: [{ allow: owner }]) {
  id: ID!
  name: String!
  email: AWSEmail!
  owner: String # required for subscriptions
}

but when I set the ownerField to be the id field:

type User @model @auth(rules: [{ allow: owner, ownerField: "id" }]) {
  id: ID!
  name: String!
  email: AWSEmail!
}

it throws the following exception while DataStore attempts to sync local data to the cloud:

{
   "errors":[
      {
         "path":["createUser"],
         "data":null,
         "errorType":"Unauthorized",
         ...
         "message":"Not Authorized to access createUser on type User"
      }
   ]
}

From what I can tell, DataStore assigns a random ID to the local model created (not the owner ID as it’s supposed to), so when trying to sync it with AppSync will get an error due to the constraint on ownerField. This is how I use DataStore to create a new user:

const init = async () => {
  const authenticatedUser = await Auth.currentAuthenticatedUser();
  const user = await DataStore.query(User, authenticatedUser.username);
  if (!user) {
    const { name, email } = authenticatedUser.attributes;
    await DataStore.save(new User({ name, email }));
  }
};

and this is the version of Amplify DataStore I am using in package.json:

"@aws-amplify/datastore": "^1.0.4",

Can confirm https://github.com/aws-amplify/amplify-js/issues/6108#issuecomment-647708908

Does NOT work:

@auth(rules: [
  { allow: private, operations: [read] },
  { allow: owner }
])

Works

@auth(rules: [
  { allow: groups, groups: ["Admin"] }
  { allow: owner }
])

@sammartinez Any timeline on this? As @johanbuys states, the docs outlined an example for multiple authorization rules which seems to not be working on DataStore.

The ability to limit certain mutations to an owner, for example delete & update, but still allow other users to subscribe to all changes (create, update, delete), seems like a common use case for a lot of apps.

This is a crucial feature for the React Native app I am working on, which uses DataStore since it needs 100% offline capabilities, and seems to be related to 2 other issues I’ve opened:

• https://github.com/aws-amplify/amplify-js/issues/6074
• https://github.com/aws-amplify/amplify-cli/issues/3777

I had this error, and it was because I specified the ownerField to be ‘owner’ (i.e. the default) when I removed that it worked fine.

I blacked it out because it was specific to my project but similar to Post (from what I recall). I did amplify push -y followed by amplify codegen models after making changes.

I started from a new project/new API with a simple but similar schema and it worked as expected. I will continue experimenting with this and I will let you know if I see this issue again. Thanks for the support.

@alexandprivate this might be of interest to you. Not using DataStore yet… I’m going to try that later.

https://github.com/aws-amplify/amplify-cli/issues/4794#issuecomment-665420716

Seems like requiring the owner field in the subscription would break a LOT of really common usecases. For example, if I want to have a chat app, and the Message type has owner - create authz, then how do I have other users get subscriptions to when new messages are posted?

Hi there @manueliglesias any good news to share so far?

Thank you so much guys for looking into this again, let us know, so we can update our schemas

I ran into pretty much the same issue with Sync error subscription failed Connection failed: {"errors":[{"message":"Validation error of type MissingFieldArgument: Missing field argument owner @ 'onCreateXXX'. In the end, I managed to work around it by explicitly specifying the owner field in the schema:

type SecondTestField
  @auth(
    rules: [
      {
        allow: owner,
        ownerField: "owner"
      }
    ]
  )
  @model {
  id: ID!
  title: String!
  description: String
  owner: String
}

Also during the debugging I realized I forgot to run amplify codegen models, so that may also be one of the steps leading to this issue.

But I don’t think it’s the only one. I now have for testing two models, one with explicit owner and one with implicit owner and when using the implicit/automatic one, I don’t get any errors, but I also don’t get subscription functionality. I need to refresh the page each time for new data to load. The implicit model is defined like this:

type TestField
  @auth(
      rules: [
        {
          allow: owner
        }
      ]
  )
  @model {
    id: ID!
    title: String!
    description: String
}

so the only difference is missing explicit owner field. Yet in code, TestField doesn’t support subscriptions (needs a page reload to display new data) and SecondTestField works as it should.

AWS libs are as follows:

        "@aws-amplify/api": "^3.1.9",
        "@aws-amplify/datastore": "^2.0.10",
        "@aws-amplify/pubsub": "^3.0.10",
        "@aws-amplify/ui-react": "^0.2.5",
        "aws-amplify": "^3.0.10",

@mkaschke you should also add @aws-amplify/datastore to your package.json file.

@mkaschke can you rename the type Subscription from annotated schema. That is overwriting the Subscription generated by CLI