Stuck with CONNECT permissions


#1

I have some problems configuring my CONNECT permissions. Here is a part of my schema

type User implements Node {
  id: ID! @isUnique
  ownedProjects: [Project!]! @relation(name: "CreatorOnProject")
}

type Project implements Node {
  id: ID! @isUnique
  creator: User! @relation(name: "CreatorOnProject")
}

and I would like to create a project like that :

mutation($userId: ID!) {
  createProject(
    creatorId: $userId,
	) {
    id
  }
}

From now everything works great but when I want to add some permissions, only the owner of the project can create it

query ($ownedProjectsProject_id: ID!, $user_id: ID!, $creatorUser_id: ID!) {
  SomeProjectExists(filter: {
    id: $ownedProjectsProject_id,
    creator: {
      AND: [
        { id: $user_id },
      	{ id: $creatorUser_id }
      ]
    }
  })
}

For some reasons this doesn’t work. When I request with a SomeUserExists and just check the user id it works well but when I want to check that the project have the ownedProjectsProject_id and/or the creator of the project is the current user I’ve got some No CONNECT permission

It looks like the project is not yet created on the connect but if it’s the case how to protect my project and doesn’t allow everyone to assign the project to them ?


#2

If this can help I have a request id with this CONNECT error eu-west-1:simple:cj6jg0chtom850142t9sj7irw


#3

I’m keen to know what the recommended solution to this is as well.


#4

@antho1404 it looks like this is the cause of the problem: https://github.com/graphcool/api-bugs/issues/161

Until that is fixed, I think the best workaround will be to avoid using nested connect mutations (i.e. use a separate mutation to connect your project to a user after it is created). Then you can use a connect permission query like this to prevent other users from connecting to it subsequently:

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

#5

Thanks for the answer and for the link to the related issue, create another mutation to connect the two nodes could be the solution for most cases but when the relation is required this could be problematic


#6

I agree it’s not ideal as it does mean that we can’t use required relationships in this scenario.

For my app, I think I will be able to live without required relationships but it will be nice to be able to use them in this scenario if nested mutations are overhauled to work better with connect permissions.


#7

You can also change the mutation to

mutation($userId: ID!) {
  createProject(
    creatorId: $userId,
    dummy: "dummy"
	) {
    id
  }
}

to allow the createProject permission to register on the field dummy.


#8

@nilan I’m not sure I really understand about the dummy field but I guess it’s a kind of hack that can make it works so that’s fine I will try this solution.

I also find this page https://www.graph.cool/docs/reference/auth/important-notes-aej3ne1eez/ that explains the problem, sorry for the post so :sweat_smile:


#9

Type permissions are not registered on nested input fields, as noted in the feature request @dankent mentioned. I agree that this behaviour is confusing (as proven by this and other threads), but this solution is definitely not a hack :slight_smile:

Thanks for bringing this up anyway! We will make this experience more coherent.


#10

Even with a dummy field in the create mutation, I still get a “No CONNECT permission” error if I use the create mutation and I have a permission on the relationship that prevents users connecting an already connected object.

It looks to me like the dummy field will ensure that a permission on the type being created will be applied but does not help with preventing the connect permission on the relationship from causing the overall mutation to fail.

Have I got this wrong?


#11

Another solution that I found is create a custom mutation for example customCreateProject that create the project with a permanent access token. Like this you can disable the connect permission or set it up appropriately. Let me know if there is some problems with this solution.


#12

I documented a more detailed description of the current behaviour here. :slight_smile:

@marsupio, using a custom mutation is not a bad idea. Are you checking the permission yourself in the function, before creating the project? Would love to learn more about this use case.

Personally, I would use the workaround with the dummy fields however.


#13

The problem is that if you have a type Project that has a field creator and you want to connect the creator only when a project is created as I understood isn’t possible because in the connect permission query you should check if SomeProjectExists with the new id and creator null, but at the moment of the creation the project doesn’t exist yet.
If you give the connect permission to everyone then a random user can come and assign itself as the creator of the Project. I haven’t considered the permission check on the project creation, so yes it would be a problem.
About the dummy field I haven’t understood how that could solve the problem.


#14

Hey folks,

I have tried the “dummy” field workaround but I’m still getting the same error when performing the create mutation: “No CONNECT permissions”

type Document @model {
id: ID! @isUnique
createdAt: DateTime!
updatedAt: DateTime!
title: String!
content: Json!
startup: Startup! @relation(name: “DocumentOnStartup”)
}

mutation {
createDocument(
title: “dummy”,
content: “{}”,
startupId: “xxx”
) {
id
}
}

Any idea?


#15

I don’t understand how this works. Could you provide a little bit of elaboration?


#16

I am also confused by this behavior. I tried adding dummy: “dummy” as well as creatorId: $userId but I get ApolloError.js:43 Uncaught (in promise) Error: GraphQL error: Unknown argument 'creatorId' on field 'createProperty' of type 'Mutation'
And
GraphQL error: Unknown argument 'dummy' on field 'createProperty' of type 'Mutation'.
As @jordan.michael.last mentioned, can you elaborate a bit more @nilan? I reviewed the information here but without seeing the model it is tough to understand.
LOVE Graph.cool but it is completely useless if I cannot save data with nested fields.