Connect permission is not correctly applied for nested connect mutations

[marktani]

Issue by schickling
Friday Sep 08, 2017 at 09:29 GMT
Originally opened as https://github.com/graphcool/prisma/issues/398

---

Issue by marktani
Monday Jul 03, 2017 at 15:06 GMT
Originally opened as https://github.com/graphcool/api-bugs/issues/161

---

What is the current behavior?

A connect permission does not grant expected rights for a nested connect mutation.

Please share the relevant part of your GraphQL schema and all functions, permissions or other project settings for easier reproduction

type Sale implements Node {
  createdAt: DateTime!
  id: ID! @isUnique
  name: String!
  store: Store! @relation(name: "SaleOnStore")
  updatedAt: DateTime!
}

type Store implements Node {
  createdAt: DateTime!
  id: ID! @isUnique
  name: String!
  sales: [Sale!]! @relation(name: "SaleOnStore")
  updatedAt: DateTime!
}

All type permissions are open to EVERYONE, and there is a CONNECT SaleOnStore permission for AUTHENTICATED users with this query:

query ($salesSale_id: ID!) {
  SomeSaleExists(filter: {
    id: $salesSale_id
    store: null
  })
}

This permission query expresses, that a sale can only be connected if it doesn't have a connected store yet.

If applicable, share the query, mutation or subscription for reproduction

First, create a new store and copy its id:

mutation {
  createStore(name: "Store") {
    id # Copy this ID!
  }
}

Then run this mutation as an authenticated user:

mutation{
  createSale(
    name: "T1"
    storeId: "<id from above>"
  ){
    id
  }
}

You will receive an error:

{
  "data": {
    "createSale": null
  },
  "errors": [
    {
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "createSale"
      ],
      "code": 3008,
      "message": "No CONNECT permissions",
      "requestId": "cj4o9qt4qamxo0177xap1j41s"
    }
  ]
}

What is the expected behavior?

The last mutation should work without a permission error.

[marktani]

Comment by schickling
Friday Sep 08, 2017 at 09:29 GMT

---

Comment by danmkent
Monday Aug 21, 2017 at 13:22 GMT

---

It looks like the problem lies in the permission for the nested connect mutation being checked before the object being created by the outer mutation is actually created.

I guess all the permissions are being checked before any data is written, which does make sense in some ways.

However, in this scenario the permission query for the nested connect mutation will likely rely on the existence of the thing being connected.

For example, even this very simple connect permission query will cause a create mutation with a nested connect mutation to fail:

query ($postsPost_id: ID!) { SomePostExists(filter: { id: $postsPost_id }) }

Presumably because at the point the permissions query is checked, the Post has not yet been created.

I would suggest that permissions for nested connect mutations are checked later in the processing order, when the object has been created and it about to actually be connected to things.

This would raise the question of what to do if the nested connect mutation failed. It may be necessary to roll back the outer mutation. For a create mutation that would be fairly easy - just delete the object.

I'm not sure if this would also affect update mutations, where rolling back would be more complex. My instinct is that it probably doesn't, as there is not the issue of the object not existing when the permission for the nested mutation is checked.

[marktani]

Comment by sorenbs
Friday Sep 08, 2017 at 21:04 GMT

---

This is a general issue relating to permission queries for nested mutations.

In the future we will make it possible to decide if a permission query should run before or after the data transformation. We will still ensure that all permissions are successful before actually committing the changes

[marktani]

Comment by divyenduz
Thursday Nov 16, 2017 at 06:19 GMT

---

Is there a workaround for this one? I have a mutation that looks like this (removed extra fields for brevity).

mutation CreatePost {
    createPost(
      postContents: [
        {
          title: "Post HC - EN"
          language: EN
        }
        {
          title: "Post HC - DE"
          language: DE
        }
      ]
    ) {
      id
    }
  }

and I think I am running into this one because a Post needs to be created before its PostContents in multiple languages. The schema looks like this (clipped for brevity).

type Post @model {
  id: ID! @isUnique
  postContents: [PostContents!]! @relation(name: "PostOnPostContents")
}

type PostContents @model {
  id: ID! @isUnique
  relatedPost: Post! @relation(name: "PostOnPostContents")
  language: Languages!
  title: String!
}

Some things I ran into, adding them here for reference:-

https://github.com/graphcool/framework/issues/398
https://github.com/graphcool/framework/issues/445
https://github.com/graphcool/framework/issues/597
https://github.com/graphcool/framework/issues/1280

https://www.graph.cool/forum/t/stuck-with-connect-permissions/665
https://www.graph.cool/docs/reference/auth/authorization/important-notes-aej3ne1eez/

[GemN]

Hello, this issue is still happening and this is highly annoying to use 2 mutations (create, then connect) or custom function as a workaround.

I wanted to know if the team is still working on as said here:
"In the future we will make it possible to decide if a permission query should run before or after the data transformation. We will still ensure that all permissions are successful before actually committing the changes"

It would really help.

[Anujraval24]

Any solution on this guys? @marktani @schickling

[noobling]

progekt ded gg