Amplify-cli: Allow `owner` to be primary key AND optional

[janhesters]

Is your feature request related to a problem? Please describe.
I have a use case, where I defined the owner as a the primary key using the @key directive. I also defined the @auth directive. But, if I make the owner optional (leaving out the !), I can't push the schema because AppSync complains that primary keys can't be optional. This usually makes since. However, in this case owner will always be defined because of the custom resolver generated by @auth.

Describe the solution you'd like
It would be cool to have a way to force push changes where you know that the resolvers generated by Amplify or custom resolvers populate the respective attribute.

Describe alternatives you've considered
The only alternative is always using a ! which can expose security risks in the case where the @key and @auth(rules: [{ ownerField }] clash. A malicious client would be able to identify as someone else.

[kaustavghosh06]

@janhesters The owner field is always defined since it's passed from cognito via the client, so the schema needs to be aware of it and will always be present when intercepting a request from the client.

[janhesters]

@kaustavghosh06 Seems like this is impossible to resolve then without custom lambda funcitons.

[Nxtra]

I can imagine many use cases where data is always accessed by only its owner.
Even a small Todo-app would only show the users' todo's.

Hence, it makes sense to allow us to use the owner field as the partitionKey and have Amplify fill it in for us.
Now the owner has to be send from the client side. But I can live with that since you can read it from the token or the userAttributes.

[Nxtra]

However I don't understand the security risk..

If the Owner is send from the client side, he will still only be able to create items with his own name as owner attribute.
Since this is verified in the resolver where authorization is only given when $allowedOwner == $identityValue.

@janhesters , I think I am missing your point here. Can you elaborate a bit more on the security risk that you mentioned.

The only alternative is always using a ! which can expose security risks in the case where the @key and @auth(rules: [{ ownerField }] clash. A malicious client would be able to identify as someone else.