Possible to protect Prisma-style nested mutations?

With Prisma, I can write nested mutations like so:

mutation{
  createPost(data: {
    body: "Hello World"
    tags: {
      create: [
        {name: "cats"}
      ],
    }
  }){
    body
    tags{
      name
    }
  }
}

Using Shield, I can set rules for createPost but any such rule bypasses all my rules on createTag. So basically if a user has permission to create a post, they can by extension create anything else that a post connects to. ie. It’s impossible to allow a user to updatePosts without also allowing them to update any tag, user, comment etc connected to that post. I think this is an inherent limitation of graqhql middleware and Prisma–they are not aware of these nested mutations and thus do not hit any mutation middleware after the top level.

Am I correct or missing something? How do people handle the case where a user is connected to a post? Can anyone update that user who can update the post?

Thanks!

[lora-reames]

@vadistic if you’re interested in modifying and exposing a subset of a schema as a new schema I recommend you check out https://github.com/mitoai/gintonic

[maticzav]

Hey @nolandg 👋,

I wouldn’t say this is a “limitation” of graphql-middleware and prisma because GraphQL does not support nested mutations as such. What prisma does is use the arguments of a function to change the nodes internally. In that sense, there are no “nested-mutations” only the Prisma API which handles connections in such a manner.

Considering this, the majority of the systems rely on unwrapped Prisma servers, if I name them so, which means that they change the schema to their needs and use prisma only as a delegation layer which happens to use GraphQL as well. I believe this might be connected to #113. So far, I haven’t come across a meaningful example which would persuade me into implementing such functionality. As a note, I would say that exposing Prisma API is far too risky because you have no control over connect and create arguments, as you already mentioned, plus you usually only need about a fifth of all the exposed functionality.

Nevertheless, if you believe this is your only option, I would go about implementing it as an argument checker. Take a look at the example below.

const hasPermission = rule({ cache: 'strict' })(
  async (parent, args, ctx, info) => {
    if (args.data.tags.create !== undefined) {
      return isUserAuthenticated(ctx)
    }
    return true
  },
)

I hope this helps you solve your problem. 🙂