Data fetching (REST) with any user-permissions relations does not work (as if ignored completely)

[ntarandek]

Bug report

Required System information

• Node.js version: 18.14.0
• NPM version: 9.3.1
• Strapi version: 4.11.1 (but this seems to be the problem for longer time)
• Database: PostgreSQL
• Operating system: MacOS Monterey
• Is your project Javascript or Typescript: Javascript

Describe the bug

I have multiple DB tables that have "user" fields which are relations to users-permissions.

All tables with issues have this relation:

"user": {
      "type": "relation",
      "relation": "oneToOne",
      "target": "plugin::users-permissions.user"
    },

This tables are for example orders on the web-shop, service records for devices and so on. All related to logged-in users.
I discovered that filtering by these relations are not working at all anymore and all my registered users could see ALL orders - good thing that I still have small number of registered users, but I presume, someone could have the same issue on very large system!

Also - population does not work on same fields - if I use "populate=*" or "populate[0]=user" in query - this does nothing.

I noticed that all other relations seem to work - filtering + population. So it seems, only relation to users-permissions is broken.
But this is quite a big issue.

I need to note that these queries did not change for over 8 months in my code so I did not even have this on the radar that it could be a problem. Now I need to write some new tests.

Steps to reproduce the behavior

Simply try REST query on the table where you want to filter by related ID - for example, if I execute this when using 4.11.1:
http://localhost:1337/api/orders?filters[$and][0][user][id][$eq]=30&sort[id]=DESC&populate[0]=user&filters[id]=366
I get all orders and I should only get the ones related to user with ID 30.
Also - none of the records have "user" populated in response.

Same thing happens on all my tables with relation to users-permissions.

Expected behavior

Filtering by related table should work.
Population should work

Code snippets

By dumping ctx.request.query into my log - I can see that REST query seems correct:

[2023-06-13 20:40:30.095] http: GET /api/orders?filters[$and][0][user][id][$eq]=30&sort[id]=DESC&populate[0]=user (171 ms) 200
[2023-06-13 20:40:35.580] orders-find-query {
  "filters": {
    "$and": [
      {
        "user": {
          "id": {
            "$eq": "30"
          }
        }
      }
    ]
  },
  "sort": {
    "id": "DESC"
  },
  "populate": [
    "user"
  ]
}

Additional context

I went back to vesion 4.6.2 just to test - and there the filtering works but population does not. I did not go back to where population works also.
If seems that from version 4.8.1 both filtering and population on these relations does not work. So, as said, this seems to be an issue for longer time.

[ntarandek]

UPDATE: I remembered that I've had similar issue with different problem - and it was resolved when I gave the right to "find" on that relation. This is the case here also. When I do that (allow authenticated users), filter works - but population still does not. Only when I also allow "findOne", population works.

This resolved my immediate issue, but we still have a huge problem. When find/findOne is not allowed, result should surely not be ignoring the filter and dumping everything out - should it? I would hugely prefer some error message like "You are filtering by field/relation that you do not have access to" (or similar).

Also, if I allow "find", anyone with valid JWT token can list all users - which is another can of worms, but probably solvable in a different manner (policies maybe) - will look into that.

[danielmuxel]

I had to create my own controllers for the content types that had a user relation. In my cases, I needed to give the users the access to view their created content (e.g. their events).

This change came some thing 4.7.x ish. If the fields could be populated user data could be leaked.

For example this controller was for my events that only the users themselves need (api/event/controllers/auth-user-events.ts)
(And yes the code could probably be better)

export = {
  async findEvents(ctx) {
    const { user } = ctx.state;

    if (!user) {
      return ctx.unauthorized("You must be logged in to perform this action.");
    }

    try {
      const query = {
        filters: {
          user: {
            id: {
              $eq: user.id,
            },
          },
        },
        populate: ["categories"], // populate some stuff here if you want
      };

      ctx.query = { ...ctx.query, ...query };

      const contentType = strapi.contentType("api::event.event");

      let entities = await strapi.entityService.findMany(
        contentType.uid,
        ctx.query
      );

      return {
        data: entities,
      };
    } catch (error) {
      return ctx.internalServerError("Oops! Something went wrong.");
    }
  },
};

This would be a router (api/eventsroutes/auth-user-events.ts)

export default {
  routes: [
    {
      method: "GET",
      path: "/auth-user-events",
      handler: "auth-user-event.findEvents",
    },
  ],
};

If other users in the frontend would have to search for that user, it is not possible. But if the user also has a open Profile that can be found the base controller filters would work.

[ntarandek]

Thank you for the reply @danielmuxel! I am aware of this option, and I already have a lot of custom controllers and methods. This just caught me a bit of guard for simple filtering/population. This is, as it seems, the way ;)

[tnavadiya]

Is this resolved? I have two users in User table. And having one user has multiple hotels. I have assigned 2 hotels to one user and 1 hotel to another user. Now I have to fetch a list of hotels assigned to logged in user. How can I do that?

[ntarandek]

@tnavadiya As far as I see - when calling via REST API, the issue is still there. But, like @danielmuxel noted, if you do it yourself via extended or custom controller, then you can get the data for specific user.

[GregorSondermeier]

The thing is:

The REST API's default controllers use sanitizeOutput() under the hood which I think will remove any private attributes and relations you don't currently have permission for from the output.

That's why if you create a custom controller which uses strapi.service, strapi.entityService or strapi.db.query to do your find request, and if you do not call sanitizeOutput() manually, those user relations will be returned.

This is somewhat documented here:
https://docs.strapi.io/dev-docs/backend-customization/controllers#sanitization-when-utilizing-controller-factories

Your only option currently is to give the find permission so that the relation does not get thrown away by sanitizeOutput. Of course this opens a door for people to load all users. You could create a custom policy which prevents direct access to the user.find route for everyone to close that door again.

There is currently an intention to completely replace the existing users-permissions plugin. Please leave your upvote here to increase priority:
https://feedback.strapi.io/feature-requests/p/field-level-permissions-end-user-management

[ntarandek]

I did not like allowing public find/findOne for users as this is way too big of a security issue - so I used custom controller, since I only need filtering by user, not the user data (by relation) itself - so I do not populate that at all.

But you are 100% correct about data sanitization @GregorSondermeier - if you get the data like this, sanitation is a must.
Not hard to call, but you need to remember it :)

[geeky-biz]

For us, upgrading from 4.5.2 => 4.10.6 caused this issue and resulted in some of our Rest APIs returning a lot more data than they should have. Eventually fixed it the way mentioned in the comments above.

Given that this issue causes a filter criteria to be silently removed, it can cause inadvertent leak of data. From that perspective:

• The severity : low seems inadequate.
• It would be ideal to document this somewhere to help prevent this for teams upgrading in the future. (happy to contribute to document if someone can point me to the right place).