My question is very similar to this question: How to do field level @auth for bi-directional one-to-many @connection with AppSync GraphQL Transform? . I'll ask with a slightly different graphql schema and hope for a more generalized answer. An example schema is:
type Blog @model @auth(rules: [{ allow: owner }, { allow: public, operations: [read] }]) {
id: ID!
name: String!
posts: [Post] @connection }
type Post @model @auth(rules: [{ allow: owner }, { allow: public, operations: [read] }]) {
title: String!
bodyText: String!
Suppose a user with username "User1" creates a Blog item. This db entry ends up as
Blog: { owner: "User1", id: "0b7f6862-1a46-4006-8953-e440334c47ec", name: "My First Blog!" }
Now User2 comes along knowing the id of User1's Blog -> namely, "0b7f6862-1a46-4006-8953-e440334c47ec". That user runs a createPost mutation with
input: { postBlogId: "0b7f6862-1a46-4006-8953-e440334c47ec", title: "I'm User1 and I Hate Puppies!", bodyText: "Puppies should be illegal!" }
This works! User2 has injected a post that will show up in queries for User1's blog when following the connection to Posts. That seems bad.
The accepted solution in the other question seems to rely on the id field in the table that's the "one" field in the "one-to-many" connection relationship happening to double as the owner field. But the problem seems to exist in any one-to-many connection, most of which won't have that constraint.
Have people found a way to protect this? I agree with the other question that this seems like something everyone must hit.
I thought of adding field level auth on the id field to restrict it to only allow read by owner plus a secondary id key to give to other users to run Gets with, but doing field level auth on required fields like id breaks subscriptions. The only other way I can think to do it is to block create and update for any types on the "many" side of the "one-to-many" connection relationship and then add custom mutations that run lambdas on the server that can query the other table to verify that the user has permissions to make the connection. But it seems like the amplify docs would have mentioned it somewhere if that's what you had to do? Would really appreciate being told I missed something dumb.
Apparently this is a duplicate of How to check permissions of an entity on create in appsync The RFC for automatically doing this is still open and hasn't had an update in a year. https://github.com/aws-amplify/amplify-cli/issues/1055