Neo4j-graphql-js: neo4jgraphql function only works within root query resolvers

[dannyvelas]

neo4graphql(object, params, ctx, info) function works only inside resolvers that are for a root query. If I queried:

{
  Employee {
    name
  }
}

This would work using this resolver:

However, If I queried:

{
  Company{
    name
    employees {
      first_name
    }
  }
}

This would return Company.name but an error is thrown when returning employees, using this resolver:

The resolver code for Employee is exactly the same.

The only difference is that the resolver code works when inside the root Query object and fails when inside a Company object.

The error thrown is:

TypeError: Cannot read property 'astNode' of undefined

[benjamin-rood]

Hi Danny, may I ask what your use case is?

Because there isn't actually any need for this unless there is some specific logic like access control you are trying to implement...

i.e. This is not technically a _bug_ as I see it, it's working as expected.

Knowing the use case might help us find a solution for you.

[loicmarie]

@benjamin-rood for my mind the use case is exactly what you said, i.e introducing resource-specific access control logic.
Isn't it a good use case ? To me, it seems essential in most of the graph-based apps

[dannyvelas]

@benjamin-rood @loicmarie Exactly. What I appreciate about the neo4jgraphql function is that it automatically determines the path to a/some node/s from a GQL query, translates it into one cypher query, and thereby avoids the N+1 problem. Also, I appreciate the filter argument to use arguments like name_contains: in GQL queries.

Would there be a way to add access control to non-root query resolvers, using the neo4jgraphql function? (To avoid writing a manual resolver, a manual solution to the N+1 problem, and manual filter arguments).

[benjamin-rood]

@loicmarie @dannyvelas

Isn't it a good use case ? To me, it seems essential in most of the graph-based apps

I could not agree more.

Would there be a way to add access control to non-root query resolvers, using the neo4jgraphql function? (To avoid writing a manual resolver, a manual solution to the N+1 problem, and manual filter arguments).

We should let @johnymontana weigh in here, but I cannot see how with the way it works currently.

introducing resource-specific access control logic.

I think it's important we make sure we are talking about the same thing, namely, we mean ABAC, and limiting access to portions of the graph and node properties, correct?

i.e. Role based access control is insufficient, we need to do two things:

1. Traverse only those areas of the graph that the requesting user (determined by the email in the JWT for example) has permission to access.
2. Only show the value for the fields they are allowed to see.

[loicmarie]

@benjamin-rood Yes, that's it. However, I don't think this can be properly done without allowing the developers to custom non-root resolvers. In my case, the logic to allow access for some resources is quite complex (we use NSMNTX to generate and handle hundreds of types in Neo4j) and need, inter alia, calls to procedures.

I am not an expert, but I think the way neo4jgraphql is currently implemented is a GraphQL antipattern that imply to handle the N+1 for those who cannot only deal with decorators (and there always will be).

Instead of generating all the Cypher query in a root resolver, and directly execute it, what about :

1. Building the Cypher subqueries in resolvers (thus avoiding the N+1 problem)
2. Executing it before sending response

As far as I can see, there is two ways of doing it, the custom way :

1. Use 'apollo-server-plugin-base' to use apollo hooks
2. In each resolver, generate the corresponding Cypher fragment and put it in the context, in something like context.current.resolver.path
3. In willSendResponse hook, get the Cypher queries from context, and compose the single query
4. Then, replace res.response.data with the query result

The second way, that seems more GraphQL-friendly, would be to use DataLoader from the GraphQL team. Didn't know about it, but it seems to perfectly fit with the mentioned problem here

[AdrienLemaire]

@loicmarie could you share an example of your current custom solutions?

My use-case: Both STAFF and ADMIN users can change user roles, but I don't want a STAFF user to change the role of an ADMIN user. Thus, I need to query the role of the user whose role is being changed before executing the mutation's cypher request, to make sure that the request user is authorized to do this operation.
It's unclear to me how we can do this at the moment.