IBX-9002: Added endpoint for list users with permission info

[ciastektk]

🎫 Issue	IBX-9002

Description:

This PR adds internal endpoint to load list of users with their permissions to by resolved context. This is required by share dialog feature to search for users by given phrase e.g.: name, surname or email. Full list of results should be displayed, grouped by users with and without permissions.

A new endpoint is not exposed in REST API to avoid public access to list of users with permissions for not logged users. To make this feature useful we cannot filter search results by permissions. Otherwise we would have to change permission settings for users to allow read User content.

Example query params:

• contentId={contentId} - (int) Content item for permission check
• locationId={locationId} - (int) target Location for permission check
• limit={limit} - (int) number of results
• offset={offset} - (int) results offset
• phrase={phrase} - (string) phrase using for search user by first name, last name or email.

###  GET /permission/users-with-permission-info/{module}/{function}

GET http://localhost/admin/permission/users-with-permission-info/content/read?contentId=43&locationId=51
Accept: application/json
X-Siteaccess: admin


GET http://localhost/admin/permission/users-with-permission-info/content/edit?contentId=43&locationId=51&phrase=user&limit=5
Accept: application/json
X-Siteaccess: admin

For QA:

Documentation:

[Steveb-p]

Current implementation seems to - correct me if I'm wrong - not distinguish between Admin UI users and "frontend" users.

I.e. you will get results with store front customer accounts, if they are created. They will also heavily pollute this list, probably making it hardly usable (if what I'm saying is true).

On a separate note: this makes any user that is able to log into the admin to discover all usernames and emails (as this is what your endpoint basically does). Given this is public and deals with sensitive information, I don't think this can be exposed like that.

Additionally, it should be enabled only if there are features that rely on it IMO. And I would even go as far as ask developer/admin to toggle availability of this endpoint on explicitly, maybe through bundle configuration.

To sum up, it's too exposed and sensitive to be enabled by default.

[ciastektk]

Current implementation seems to - correct me if I'm wrong - not distinguish between Admin UI users and "frontend" users.

I.e. you will get results with store front customer accounts, if they are created. They will also heavily pollute this list, probably making it hardly usable (if what I'm saying is true).

On a separate note: this makes any user that is able to log into the admin to discover all usernames and emails (as this is what your endpoint basically does). Given this is public and deals with sensitive information, I don't think this can be exposed like that.

Additionally, it should be enabled only if there are features that rely on it IMO. And I would even go as far as ask developer/admin to toggle availability of this endpoint on explicitly, maybe through bundle configuration.

To sum up, it's too exposed and sensitive to be enabled by default.

Sorry, previous version was sent for review too early. I pushed new version including new Query based on new Criteria (the previous ones did not work for elasticsearch and solr) and now guest and corporate users are skipped.

About availability of this endpoint. I have same feelings like you, and access for sensitive informations worries me. I'd to discuss this internally.

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud