Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

@querystring shouldn't list userids #1777

Open
djay opened this issue Apr 30, 2024 · 0 comments · May be fixed by #1824
Open

@querystring shouldn't list userids #1777

djay opened this issue Apr 30, 2024 · 0 comments · May be fixed by #1824

Comments

@djay
Copy link
Member

djay commented Apr 30, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant