Мой вопрос очень похож на этот вопрос: Как сделать уровень поля @auth для двунаправленного соединения один-ко-многим с AppSyn c GraphQL Transform? . Я спрошу с немного другой схемой graphql и надеюсь на более обобщенный ответ. Пример схемы:
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!
Предположим, что пользователь с именем пользователя "User1" создает элемент блога. Эта запись в БД заканчивается как
Blog: { owner: "User1", id: "0b7f6862-1a46-4006-8953-e440334c47ec", name: "My First Blog!" }
. Теперь User2 узнает идентификатор блога User1 -> а именно, «0b7f6862-1a46-4006-8953-e440334c47e c». Этот пользователь запускает мутацию createPost с
input: { postBlogId: "0b7f6862-1a46-4006-8953-e440334c47ec", title: "I'm User1 and I Hate Puppies!", bodyText: "Puppies should be illegal!" }
Это работает! Пользователь2 ввел сообщение, которое будет отображаться в запросах к блогу Пользователя1 при подключении к сообщениям. Это кажется плохим.
Принятое решение в другом вопросе, похоже, основывается на поле id в таблице, которое является полем "one" в отношении соединения "один-ко-многим", которое удваивается как владелец поле. Но проблема, кажется, существует в любом соединении один-ко-многим, у большинства из которых нет этого ограничения.
Люди нашли способ защитить это? Я согласен с другим вопросом, что это похоже на то, что каждый должен ответить.
Я думал о добавлении аутентификации уровня поля в поле идентификатора, чтобы ограничить его разрешением только чтения владельцем и дополнительным ключом идентификатора, чтобы другие пользователи могли выполнять его с Gets, но выполнял аутентификацию на уровне поля в таких обязательных полях, как id ломает подписки. Единственный другой способ, которым я могу думать, это заблокировать создание и обновление для любых типов на стороне «многие» отношения «один ко многим», а затем добавить пользовательские мутации, которые запускают лямбда-выражения на сервере, который может запрашивать другая таблица, чтобы убедиться, что у пользователя есть разрешения на подключение. Но похоже, что документы по усилению упомянули бы это где-нибудь, если бы это было то, что вы должны были сделать? Буду очень признателен, если мне скажут, что я что-то упустил.