Problem

Restapi @querystring doesn’t require authentication.

This lists the users vocabulary which can list all users id and full name. Depending how plone is configured, the email could be the id.

e.g.

curl https://www.plone-demo.info/++api++/@querystring

      "sortable": true, 
      "title": "Creator", 
      "values": {
        "admin2": {
          "title": ""
        }, 
        "editor": {
          "title": ""
        }, 
        "reader": {
          "title": ""
        }, 
        "siteadmin": {
          "title": ""
        }
      }, 
      "vocabulary": “plone.app.vocabularies.Users"

The group names is also information that you might not want to make public.

Volto uses this for search blocks but I don’t think it needs to be public as it should only be needed for the search block editing UI.
The editor could add a filter that uses that vocabulary but I don't think it makes sense to have a filter on users on a public site. The editor should probably be in control of which vocab they want to make public via adding filters/facets.

If you set “many users” then it works around the issue

Proposed solution

• make @querystring an protected editor only call and use a different method to get the vocab for the filters?
  • filters/facets should probably get the unique values of the index anyway, instead of the vocab. This way only data used is revealed.
  • what the options are for a querystring doesn't need to be made public. The block should have the data on save to know what query to make

Other solutions considered

• don't allow users or groups to be filters and don't include those vocab in the querystring results, or return empty lists.
  • but then the editor can't set a base query for a listing or search block to only show a content created by a single user or group?
• seperate out the vocab calls into different api calls so permissions can be applied per vocab?

Context

A related bug is that if you visit a page with a search-block it will make 2 requests to @querytring instead of one. This might be because the querystring api seems to be doing a dual purpose of being used to vocab as well as querystring options?