[graphql] controller bypassed when querying nested relations

[8byr0]

Bug report

Describe the bug

When using custom processing in a model controller to filter nested relations, it's bypassed by graphql plugin.

Steps to reproduce the behavior

1. Create a model B
2. Create a model A with a field entities (one to many : B)
3. Edit api/A/controllers/a.js and add a custom findOne controller (but same behaviour with all controllers) :

module.exports = {
    lifecycles: {
        async findOne(ctx) {
           const data = // query data
           data.entities = [];
           return data;
        }
    }
}

4. query you model via graphql

query MyModelA {
  projectState(id:"azertyuiop"){
        id
  	entities {
          id
        }
    }
}

Expected behavior

The data returned by graphql plugin should be the one returned by controller:

{
  "data": {
    "a": {
      "id": "azertyuiop",
      "entities": []
    }
  }
}

Instead we receive this:

{
  "data": {
    "a": {
      "id": "azertyuiop",
      "entities": [
        {
          "id": "abcdefgh",
        },
        {
          "id": "ijklmnop",
        },
      ]
    }
  }
}

Screenshots

N/A

Code snippets

If applicable, add code samples to help explain your problem.

System

• Node.js version: 10.19.0
• YARN version: 1.22.5
• Strapi version: 3.3.3
• Database: Mongo DB
• Operating system: Ubuntu 20.04

Additional context

After investigating a bit, it seems that graphql plugin queries manually nested relations without using controller for each queried relation:

    // strapi-plugin-graphql/services/data-loader.js:159
    return strapi.plugins['content-manager'].services['contentmanager'].fetchAll(modelUID, params);

This results in a query to ORM model (mongoose, here) instead of controller.

I'm not really familiar with apollo server and the way it's been implemented here but wouldn't it be possible to query nested relations via their controller ?

[8byr0]

Maybe somehow related to #8671

[8byr0]

@derrickmehaffy I made a repro repo https://github.com/8byr0/graphqlIssue8735

Setup

Install

yarn
yarn build
yarn develop

Configure

Edit public permissions (no need for authentication to reproduce)

go to http://localhost:1337/admin/settings/users-permissions/roles/2 (Public role)

Allow all nested-entity and root-entity actions.

Create sample models

1. Create a rootEntity, name it as you want (e.g root01)
2. Create multiple nestedEntities, name them incrementally (e.g nested01, nested02)

Reproduce

A controller in api/root-entity/controllers/root-entity.js will automatically drop nested_entities on find

A controller in api/nested-entity/controllers/nested-entity.js will log when called

REST

Reach http://localhost:1337/root-entities, you'll see a response without nested entities.

[
  {
    "id": 1,
    "name": "root01",
    "created_at": "2020-11-26T08:11:31.753Z",
    "updated_at": "2020-11-26T08:15:05.877Z"
  }
]

Graphql

From http://localhost:1337/graphql run

query MyNestedEntities {
  rootEntities {
    id
    name
    nested_entities {
      id
      name
    }
  }
}

It should return:

{
  "data": {
    "rootEntities": [
      {
        "id": "1",
        "name": "root01",
        "nested_entities": [
          {
            "id": "1",
            "name": "nested01"
          },
          {
            "id": "2",
            "name": "nested02"
          }
        ]
      }
    ]
  }
}

[derrickmehaffy]

Thank you @8byr0 I'll test it either today or tomorrow 👍

[derrickmehaffy]

@8byr0 you are correct that our GraphQL plugin has it's own population code, In a case like this you will likely need to create your own custom queries/resolvers.

To give a bit of context on how everything works, I'll share a part of one of our engineering diagrams (we plan to change this in the future but no ETA)

[8byr0]

Thanks for your reply and explanations.
The problem with your suggestion of using custom query/resolver is that these pieces do not have access to query context.
So when you want to implement a custom logic based on user role / id or any other request params, this is just impossible.

The only solution I see to solve this is to use a depth of 0 but let's use REST then... Have you got other ideas to bypass the plugin's limitations?

And is there a particular reason why this has been designed like this ? Would a PR replacing calls to resolvers with calls to controllers for population be accepted ?

[derrickmehaffy]

And is there a particular reason why this has been designed like this ? Would a PR replacing calls to resolvers with calls to controllers for population be accepted ?

To the why, I think the goal was just to make it simple, we weren't planning for the future. We have some plans to modify this and make it far more efficient.

As to the PR question I'll point that at @alexandrebodin.

[sebastian-ludwig]

@derrickmehaffy Could you give us some more information about your future plans regarding this issue please?
I see the problem, when we do not use Controllers and policies for nested relations, there is the risk, that one can access restricted data:

// everyone should do this
query AllComaniesWithJobs {
  companies {
    id
    jobs {
      id
      position
    }
  }
}

// only Company-Admins should do this
query AllComaniesWithApplicants {
  companies {
    id
    jobs {
      id
      users_permissions_user {
        id
        email
      }
    }
  }
}

Have you got a solution for restricting the second request?

[derrickmehaffy]

@sebastian-ludwig I don't currently have any information on it as our v4 is still in it's design phase (we haven't even finished the RFC yet to release for comment). I'm not sure if something like this will be implemented in the initial v4 or not.

cc @alexandrebodin / @sam-pires / @JabStrapi

[sebastian-ludwig]

Thanks @derrickmehaffy. Any feedback or advice would be appreciated, because currently I see a big GraphQL security issue, when all nested relations are accessible to the requester without any policy checks.
Or can I intercept those nested resolvers somehow?